RE: [midcom] pre-midcom candidates

From daemon@optimus.ietf.org Thu Nov 1 10:03:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20390 for ; Thu, 1 Nov 2001 10:03:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04166 for midcom-archive@odin.ietf.org; Thu, 1 Nov 2001 10:03:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03792; Thu, 1 Nov 2001 09:59:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03760 for ; Thu, 1 Nov 2001 09:59:33 -0500 (EST) Received: from avgw.vxserver.com (mail.ridgeway-sys.com [194.128.67.178]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20265 for ; Thu, 1 Nov 2001 09:59:29 -0500 (EST) Received: from ridgeway.ridgeway-sys.com ([10.1.1.1]) by avgw.vxserver.com (NAVGW 2.5.1.2) with SMTP id M2001110114564122258 ; Thu, 01 Nov 2001 14:56:41 GMT Received: by ThisAddressDoesNotExist with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Nov 2001 14:58:49 -0000 Message-ID: <00533D13955AD411AF3800A0C9B426390EC4AF@ThisAddressDoesNotExist> From: Barry Scott To: "'James Ho'" , midcom@ietf.org Subject: RE: [midcom] pre-midcom candidates Date: Thu, 1 Nov 2001 14:58:42 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C162E5.B2715850" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C162E5.B2715850 Content-Type: text/plain; charset="ISO-8859-1" The policy we need turns out to be the default for many enterprises already. Typical behavour is to prevent UDP from the outside to get inside. But once a UDP packet from the inside is sent to the outside the firewall will pinhole itself to allow return traffic. After a period of inactivity the firewall will close the pinhole, for example after 45 seconds. BArry -----Original Message----- From: James Ho [mailto:jamesho37@hotmail.com] Sent: 31 October 2001 22:20 To: midcom@ietf.org Subject: RE: [midcom] pre-midcom candidates As I understand it, the Davies proposal requires an open UDP port on the firewall for media traversal. I can't think of many/any enterprises being willing to implement such a firewall policy. Or maybe my understanding is faulty?? james _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C162E5.B2715850 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] pre-midcom candidates

The policy we need turns out to be the default for = many
enterprises already.

Typical behavour is to prevent UDP from the = outside
to get inside. But once a UDP packet from the = inside
is sent to the outside the firewall will pinhole = itself
to allow return traffic. After a period of = inactivity
the firewall will close the pinhole, for example = after
45 seconds.

= BArry

-----Original Message-----
From: James Ho [mailto:jamesho37@hotmail.com]<= /FONT>
Sent: 31 October 2001 22:20
To: midcom@ietf.org
Subject: RE: [midcom] pre-midcom candidates

As I understand it, the Davies proposal requires an = open
UDP port on the firewall for media traversal. I = can't think
of many/any enterprises being willing to implement = such a
firewall policy. Or maybe my understanding is = faulty??

james

_______________________________________________________________= __
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

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

------_=_NextPart_001_01C162E5.B2715850-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Nov 1 11:22: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 ESMTP id LAA22982 for ; Thu, 1 Nov 2001 11:22:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07279 for midcom-archive@odin.ietf.org; Thu, 1 Nov 2001 11:22: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 LAA07238; Thu, 1 Nov 2001 11:18:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07209 for ; Thu, 1 Nov 2001 11:18:20 -0500 (EST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22843 for ; Thu, 1 Nov 2001 11:18:15 -0500 (EST) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 1 Nov 2001 08:17:48 -0800 Received: from 157.54.8.155 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 01 Nov 2001 08:17:42 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 1 Nov 2001 08:17:05 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 1 Nov 2001 08:17:05 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3541.1); Thu, 1 Nov 2001 08:16:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [midcom] pre-midcom candidates Date: Thu, 1 Nov 2001 08:16:20 -0800 Message-ID: Thread-Topic: [midcom] pre-midcom candidates thread-index: AcFi5dCtFp0BDxujTx6Am4t+Vlkc3wACm1dg From: "Christian Huitema" To: "Barry Scott" , "James Ho" , X-OriginalArrivalTime: 01 Nov 2001 16:16:18.0673 (UTC) FILETIME=[89CDE610:01C162F0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA07210 Sender: 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 Barry, This is exactly the same firewall requirement as STUN. -----Original Message----- From: Barry Scott [mailto:bscott@ridgewaysystems.com] Sent: Thursday, November 01, 2001 6:59 AM To: 'James Ho'; midcom@ietf.org Subject: RE: [midcom] pre-midcom candidates > The policy we need turns out to be the default for many > enterprises already. > Typical behavour is to prevent UDP from the outside > to get inside. But once a UDP packet from the inside > is sent to the outside the firewall will pinhole itself > to allow return traffic. After a period of inactivity > the firewall will close the pinhole, for example after > 45 seconds. Barry, This is exactly the same requirement as STUN, with the difference that STUN does not require an infrastructure in the middle of the network. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Nov 1 11:35: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 ESMTP id LAA23210 for ; Thu, 1 Nov 2001 11:35:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07886 for midcom-archive@odin.ietf.org; Thu, 1 Nov 2001 11:35:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07802; Thu, 1 Nov 2001 11:32: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 LAA07773 for ; Thu, 1 Nov 2001 11:32:31 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23120 for ; Thu, 1 Nov 2001 11:32:26 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.04) id A91DAA360118; Thu, 01 Nov 2001 11:32:29 -0500 Message-ID: <016501c162f2$6b37a0e0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Barry Scott" , "'James Ho'" , References: <00533D13955AD411AF3800A0C9B426390EC4AF@ThisAddressDoesNotExist> Subject: Re: [midcom] pre-midcom candidates Date: Thu, 1 Nov 2001 11:29:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit What percentage of NAT/FW are symmetric as opposed to full-cone as described in the STUN proposal? There is some debate whether or not the interim solution needs to address the symmetric NAT problem. If the great majority of existing FW/NAT are symmetric, we probably need to include it now. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Barry Scott" To: "'James Ho'" ; Sent: Thursday, November 01, 2001 9:58 AM Subject: RE: [midcom] pre-midcom candidates > The policy we need turns out to be the default for many > enterprises already. > > Typical behavour is to prevent UDP from the outside > to get inside. But once a UDP packet from the inside > is sent to the outside the firewall will pinhole itself > to allow return traffic. After a period of inactivity > the firewall will close the pinhole, for example after > 45 seconds. > > BArry > > -----Original Message----- > From: James Ho [mailto:jamesho37@hotmail.com] > Sent: 31 October 2001 22:20 > To: midcom@ietf.org > Subject: RE: [midcom] pre-midcom candidates > > > As I understand it, the Davies proposal requires an open > UDP port on the firewall for media traversal. I can't think > of many/any enterprises being willing to implement such a > firewall policy. Or maybe my understanding is faulty?? > > james > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Nov 1 11:53:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23582 for ; Thu, 1 Nov 2001 11:53:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08284 for midcom-archive@odin.ietf.org; Thu, 1 Nov 2001 11:53: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 LAA08110; Thu, 1 Nov 2001 11:40: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 LAA08079 for ; Thu, 1 Nov 2001 11:40:39 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23321 for ; Thu, 1 Nov 2001 11:40:34 -0500 (EST) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.wcom.com (PMDF V5.2-33 #47837) with ESMTP id <0GM400DBFRMTKL@firewall.wcom.com> for midcom@ietf.org; Thu, 1 Nov 2001 16:40:06 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GM400M01RMMRQ@pmismtp04.wcomnet.com>; Thu, 01 Nov 2001 16:40:05 +0000 (GMT) Received: from rccc6131 ([166.34.120.127]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GM400KEMRLSL2@pmismtp04.wcomnet.com>; Thu, 01 Nov 2001 16:39:29 +0000 (GMT) Date: Thu, 01 Nov 2001 10:39:22 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] pre-midcom candidates - the Davies Critique In-reply-to: To: "'Christian Huitema'" , "'Steve Davies'" , "'midcom'" Cc: "'Melinda Shore'" , "'Jonathan Rosenberg'" Reply-to: christopher.a.martin@wcom.com Message-id: <003401c162f3$c3817220$7f7822a6@rccc6131.mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 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 Anything intended to keep a "pinhole" open is actually pretty inefficient in behavoir...the Davies proposal is actually on an as needed basis which is more efficient. Also the ablity to maintain "control" by the IT managers is inherent to the Davies design, IMHO, since the enforcement is maintained both at the AP(where policy can be enforced), the firewall(s), and the SIP proxies (in the case of SIP signaling). I need to continue researcing the Davies proposal, but these were my initial opinions on the draft. The other proposals place enforcement at the clients, as they are maintaining the pinholes through the firewall, not a place that many IT managers typically allow enforcement to placed (except for possibly the SOHO). > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Christian Huitema > Sent: Wednesday, October 31, 2001 4:26 PM > To: Steve Davies; midcom > Cc: Melinda Shore; Jonathan Rosenberg > Subject: RE: [midcom] pre-midcom candidates - the Davies Critique > > > Steve, > > Your point regarding "Stun and firewalls" is mistaken. The STUN > requirement is that if there is a firewall, it let a response > come in to > a packet sent from an internal port. This is the default behavior of > most "residential NAT/firewall", and it is also an optional > behavior in > many enterprise firewalls. Whether such a policy is deemed > acceptable by > the local IT manager is debatable -- there are pros and cons. > > -- Christian Huitema > > -----Original Message----- > From: Steve Davies [mailto:sdavies@ridgewaysystems.com] > Sent: Wednesday, October 31, 2001 12:57 PM > To: 'midcom' > Cc: 'Melinda Shore'; 'Jonathan Rosenberg' > Subject: RE: [midcom] pre-midcom candidates - the Davies Critique > > (Apologies if you get this twice. The first attempt was too > long for the > mailing list so I've deleted the history.).... > Naturally, I don't entirely agree with Jonathan's analysis. Here is > mine: > The Sen Proposal: > ----------------- > I don't see the Sen proposal as an adequate near-term/pre-midcom > solution for two main reasons: > (a) it requires changes to the protocol: > ---------------------------------------- > In order to make the Sen proposal work we are told that a new service > tag must be incorporated in the SIP Register request and a > new SIP Ping > (keep-alive) method must be incorporated. Not only will this take time > to implement in SIP but presumably we'll also need corresponding > protocol changes for Megaco, MGCP, H.323, etc. Or is Midcom > SIP-specific? > (b) it requires behavioural changes to the client: > -------------------------------------------------- > It requires symmetric RTP and the continual transmission of > RTP and RTCP > packets to keep the NAT bindings open. While symmetric RTP > may be a good > thing, that doesn't imply all applications have constant > bi-directional > streams - think of 'broadcast' type applications. Also why should > terminals be expected to turn off silence suppression? How > are endpoints > to know when and when not to make this behavioural change? > Other weaknesses of the proposal include a requirement on terminals to > signal to the SIP proxy when they are behind a NAT. It is not > explained > how they are supposed to know whether or not they are. > Additionally, the > use of random ports on the RTP Proxy makes it difficult to > protect such > a device with a regular filtering firewall. Such > configurations would be > required for an enterprise do-it-yourself solution(the > enterprise is its > own provider) and by service providers wanting to protect > their networks > and service from DoS attacks. > Note that correction of all these shortcomings results in the same > architecture and method outlined in the Davies proposal. > The Rosenberg/STUN Proposal: > ---------------------------- > Whilst I acknowledge the STUN proposal provides a method to determine > the type of NAT a terminal may be behind, I view the proposal as > incomplete and potentially impractical candidate as a > near-term/pre-midcom solution. > a) Firewalls are everywhere: > ---------------------------- > Whenever a firewall is deployed in conjunction with a NAT, > irrespective > of the type of NAT, the net result is equivalent to what the > STUN method > describes as a Symmetric NAT. In the case of symmetric NATs, the > Rosenberg proposal acknowledges that a media > intermediary/relay (or RTP > Proxy) is required. However, the STUN proposal doesn't inform us what > the architecture and method are for making calls in this > case, although > Jonathan acknowledges in his email that there are three > solutions - the > Davies proposal, the Sen proposal and an unpublished STUN proposal. > Firewalls are a fact of life in all enterprises connected to the > internet. An ever-increasing number of users are installing > firewalls in > their homes as well. The majority of calls will require a media > intermediary/RTP Proxy. In other words, VoIP providers will have to > install media intermediaries from Day One of any service. Can you > imagine the subscription scenario if they don't: > Customer: 'Please may I subscribe to your service' > Provider: 'Is your terminal behind a firewall?' > Customer: 'Yes' > Provider: 'Sorry our service won't work for you' or 'Yes, but please > place your terminal outside the firewall' or 'Yes, but you > can only call > other people not behind a firewall or symmetric NAT'. > This is not what the VoIP industry needs right now! > b) Too early to optimise: > ------------------------- > The STUN proposal boils down to a port saving technique for VoIP > providers. But in a nascent market its impractical to start > with a port > saving technique particularly when its unquantifiable how many ports a > provider may save. What providers need is a solution that is > deployable > in all cases - that implies a media intermediary solution. Trying to > combine a port saving technique in conjunction with a media > intermediary > solution will add complexity that will delay and stall the > VoIP market. > From a provider's perspective, this delay and additional testing could > far outweigh any savings gained by requiring fewer media intermediary > ports. > c) Unproven: > ------------ > i) TIMEOUTS. When a user is behind a firewall or symmetric > NAT, to avoid > use of a media intermediary the terminal must invoke the STUN protocol > on a call by call basis. The STUN protocol requires potentially > significant timeouts to expire in order to determine whether media may > go direct. What will this do to call setup times? > ii) NETWORK BASED NATS. There may be cases where the terminal > determines > that the media may go direct, but in fact the media passes through > network based NATs and the call will fail. This would typically happen > at the provider boundary, because the provider uses some internal > addressing scheme or when passing from IPv4 to IPv6 networks. The > solution would be to place the STUN server on the remote side of those > network based NATs, but this would have the consequence of tromboning > the media via those network based NATs for 'provider-internal' calls, > defeating the reason for STUN. Alternatively, multiple STUN servers > would need to be deployed - one for each different NAT location, but > that then poses the question of how a terminal would know which STUN > server to use on a call-by-call basis. > Davies proposal: > ---------------- > The Davies proposal is very midcom-like. The Proxy Extension > Agent (PEA) > is like a MIDDLEBOX and the Application Proxy (AP) is like a MIDCOM > AGENT. The AP is responsible for getting publicly reachable transport > addresses on the PEA for external calls and publishing those addresses > in the protocol messages. > The Davies proposal simplifies the security policy problem being > grappled with by MIDCOM to a very simple static policy > administered and > controlled by the IT manager and implemented on existing > firewalls. Just > three static pinholes are required to be configured in the firewall. > Furthermore, these pinholes are outbound pinholes(i.e. out from the > enterprise). > Jonathan writes that in the Davies draft there are issues to do with > consistency with enterprise firewall policy, but this is > unsubstantiated. When details of these issues are provided, we will be > happy to discuss them. The Davies method is entirely consistent with > enterprise firewall policy - it is similar to, but actually far more > restrictive than the firewall policy that allows web browsing for > example. The Davies proposal's policy has been vetted by service > providers and is already in commercial deployments - we can > only assume > enterprises find it acceptable. > As well as being midcom-like, the Davies method has many other > significant advantages: > * It provides a 100% solution. It will work anywhere no > matter how many > and what type and combination of firewalls and NATs there are. > * No change is required to any of the protocols. It is not even > necessary for endpoints to implement symmetric RTP. > * The implementation can be made transparent to the endpoints or be > implemented by them. > * Enterprise or Service Provider deployments are possible. The PEA may > be deployed within a service provider's network or within the > DMZ of an > enterprise's own service centre. > * Passing through a media intermediary is seen as enhancing > security and > saving IP addresses. Hiding an enterprise IP address from the remote > party (only the transport addresses of the PEA are published in > messages) is seen as a benefit and enables the enterprise to use the > same IP address used for other Internet traffic. > * Service Providers see a benefit in handling the media > through PEA for > several reasons. It enables them to hide the transport addresses of > their other service equipment. It provides them with a > suitable point to > implement wire-tapping (e.g.CALEA) - ITSPs in many countries are bound > to provide such capabilities. It also provides them with a media QOS > execution point and it provides suitable IPv4/IPv6 migration boundary > points. > Jonathan seeks to belittle the Davies proposal by likening it to RSIP. > I'm not sure what the point is here. It is true that we have borrowed > and learnt from many of the principles and techniques used within the > Internet. That's why we have well known ports, outbound initiated > connections, and TCP multiplexing, so it's not surprising the > method is > recognisable and architecturally looks similar to other > protocols. What > is unique, is the way in which this method combines the different > Internet techniques together with the transport of real-time > UDP streams > without any tunneling overhead. > In fact, the single disadvantage of the Davies proposal is that it > requires media intermediaries, but no-one has devised a non-media > intermediary solution that solves all of today's firewall and NAT > deployments. In any case, media intermediaries are not of much concern > to service providers because they will co-locate those intermediaries > with their access equipment in their POPs. In due course, those > intermediaries may even be implemented in the access routers or Midcom > will obviate them. > Pre-Midcom Recommendation: > -------------------------- > Jonathan writes that he wants to tackle the harder stuff, > i.e. firewalls > and symmetric NATs, later. The fact of the matter is that the Davies > proposal has solved the harder stuff already. It is the > Davies proposal > that is the low-hanging fruit because it addresses 100% of deployments > and it has working examples. Surely this is where a > pre-midcom solution > must start. A VoIP provider needs it from Day One because it is very > likely some/many customers will have a firewall or symmetric > NAT. If in > time, providers are seeking more efficient deployments or are > seeking to > reduce costs, then the Davies solution is easily extended to > incorporate > a STUN-like method. But before embarking on this effort it > would be wise > to judge the market need and determine when MIDCOM will kick in. > Steve Davies > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Nov 1 12:06:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23834 for ; Thu, 1 Nov 2001 12:06:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09277 for midcom-archive@odin.ietf.org; Thu, 1 Nov 2001 12:06:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09223; Thu, 1 Nov 2001 12:03:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09192 for ; Thu, 1 Nov 2001 12:03:36 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23806 for ; Thu, 1 Nov 2001 12:03:31 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.04) id A067D1070118; Thu, 01 Nov 2001 12:03:35 -0500 Message-ID: <018701c162f6$c3c307a0$2300000a@acmepacket.com> From: "Bob Penfield" To: "midcom" Date: Thu, 1 Nov 2001 12:00:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [midcom] framework-04 comments Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi all, I do have some nits on the framework: 1) I think all occurrences of "In-path" should be removed from section 7. 2) Figure 3 is not correct. In order to match the timeline flows it should be: ___________ --->| SIP |<-----\ / | Proxy | \ | |_________| | 1| |^ ^| 4| | || || | |8 2||3 7||6 |5 ______________ | || || | ______________ | |<-/ _v|____|v____ \->| | | External | Na | | Nc | SIP Phone | | SIP phone |>------->| Middlebox |>------>| within | | |<-------<|___________|<------<| Pvt. domain| |____________| Nb Nd |____________| The text in the 2nd paragraph of 7.0 needs to be updated to reflect the above. 3) Just for correctness, the 100Trying message should precede communication with the middlebox in all the timeline flows (sections 7.1, 7.2 & 7.2). 4) Section 7.2 & 7.3: The real reason that the SIP proxy must communicate with the NAT middlebox before sending the INVITE on is that it needs to change the IP address(es) and port(s) in the SDP of the INVITE to those allocated by the middlebox. If it does not, the called party will send its RTP media to the wrong address+port. 5) Section 7.2 & 7.3: The timeline explicitly indicates that the SDP is modified for the 200-OK response to the INVITE, but not for the INVITE itself going from the proxy to the private phone. 6) Section 7.2 & 7.3: The "Modify SDP" for the BYE request and the 200-OK response to the BYE (top of page 24, bottom of page 26 and middle of page 27) should be removed. This message will not contain SDP. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Nov 1 12:28:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24387 for ; Thu, 1 Nov 2001 12:28:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09705 for midcom-archive@odin.ietf.org; Thu, 1 Nov 2001 12:28: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 MAA09610; Thu, 1 Nov 2001 12:25: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 MAA09578 for ; Thu, 1 Nov 2001 12:25:26 -0500 (EST) Received: from hotmail.com (f164.pav1.hotmail.com [64.4.31.164]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24321 for ; Thu, 1 Nov 2001 12:25:21 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 1 Nov 2001 09:24:55 -0800 Received: from 207.5.1.168 by pv1fd.pav1.hotmail.msn.com with HTTP; Thu, 01 Nov 2001 17:24:55 GMT X-Originating-IP: [207.5.1.168] From: "James Ho" To: bpenfield@acmepacket.com, bscott@ridgewaysystems.com, midcom@ietf.org Subject: Re: [midcom] pre-midcom candidates Date: Thu, 01 Nov 2001 09:24:55 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Nov 2001 17:24:55.0419 (UTC) FILETIME=[1F937CB0:01C162FA] Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Why could'nt tunnel-mode IPsec be used beween an IPsec end-point in the enterprise and another in the SP network to tunnel H.323/SIP traffic across firewalls? The auth/integrity checking within ESP with null encryption should allow for a secure tunnel improving enterprise IT confidence. Plus its a standard approach vs. the "proprietary' approaches proposed. To address NAT issues, the internal IPsec end-point could have a public IP address. I don;t performance/latency will be an issue as IP storage folks are considering tunnel-mode IPsec to be a mandatory requirement for all IP storage protocols (i.e. iSCSI, FCIP, etc). Saqib >From: "Bob Penfield" >To: "Barry Scott" , "'James Ho'" >, >Subject: Re: [midcom] pre-midcom candidates >Date: Thu, 1 Nov 2001 11:29:46 -0500 > >What percentage of NAT/FW are symmetric as opposed to full-cone as >described >in the STUN proposal? There is some debate whether or not the interim >solution needs to address the symmetric NAT problem. If the great majority >of existing FW/NAT are symmetric, we probably need to include it now. > >(-:bob > >Robert F. Penfield >Chief Software Architect >Acme Packet, Inc. >130 New Boston Street >Woburn, MA 01801 >bpenfield@acmepacket.com > >----- Original Message ----- >From: "Barry Scott" >To: "'James Ho'" ; >Sent: Thursday, November 01, 2001 9:58 AM >Subject: RE: [midcom] pre-midcom candidates > > > > The policy we need turns out to be the default for many > > enterprises already. > > > > Typical behavour is to prevent UDP from the outside > > to get inside. But once a UDP packet from the inside > > is sent to the outside the firewall will pinhole itself > > to allow return traffic. After a period of inactivity > > the firewall will close the pinhole, for example after > > 45 seconds. > > > > BArry > > > > -----Original Message----- > > From: James Ho [mailto:jamesho37@hotmail.com] > > Sent: 31 October 2001 22:20 > > To: midcom@ietf.org > > Subject: RE: [midcom] pre-midcom candidates > > > > > > As I understand it, the Davies proposal requires an open > > UDP port on the firewall for media traversal. I can't think > > of many/any enterprises being willing to implement such a > > firewall policy. Or maybe my understanding is faulty?? > > > > james > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www1.ietf.org/mailman/listinfo/midcom > > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Nov 1 12:51:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25459 for ; Thu, 1 Nov 2001 12:51:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10625 for midcom-archive@odin.ietf.org; Thu, 1 Nov 2001 12:51: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 MAA10576; Thu, 1 Nov 2001 12:48: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 MAA10545 for ; Thu, 1 Nov 2001 12:48:22 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25343 for ; Thu, 1 Nov 2001 12:48:16 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.04) id AADF733300AC; Thu, 01 Nov 2001 12:48:15 -0500 Message-ID: <01a601c162fd$00a8e080$2300000a@acmepacket.com> From: "Bob Penfield" To: , "'Christian Huitema'" , "'Steve Davies'" , "'midcom'" Cc: "'Melinda Shore'" , "'Jonathan Rosenberg'" References: <003401c162f3$c3817220$7f7822a6@rccc6131.mcit.com> Subject: Re: [midcom] pre-midcom candidates - the Davies Critique Date: Thu, 1 Nov 2001 12:45:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Christopher A. Martin" To: "'Christian Huitema'" ; "'Steve Davies'" ; "'midcom'" Cc: "'Melinda Shore'" ; "'Jonathan Rosenberg'" Sent: Thursday, November 01, 2001 11:39 AM Subject: RE: [midcom] pre-midcom candidates - the Davies Critique > Anything intended to keep a "pinhole" open is actually pretty inefficient in > behavoir...the Davies proposal is actually on an as needed basis which is > more efficient. Also the ablity to maintain "control" by the IT managers is > inherent to the Davies design, IMHO, since the enforcement is maintained > both at the AP(where policy can be enforced), the firewall(s), and the SIP > proxies (in the case of SIP signaling). I need to continue researcing the > Davies proposal, but these were my initial opinions on the draft. > > The other proposals place enforcement at the clients, as they are > maintaining the pinholes through the firewall, not a place that many IT > managers typically allow enforcement to placed (except for possibly the > SOHO). > You are assuming that IT manager have "control" over the Application Proxy. I don't think that will be the case. If the APs are built into end-points, the enforcement is still at the client. Both the Davies and the STUN proposals involve poking UDP holes thru the NAT/FW for RTP by devices that are "clients" as far as an IT manager is concerned. Davies just adds the tunnel for the signalling. > > > -----Original Message----- > > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > > Christian Huitema > > Sent: Wednesday, October 31, 2001 4:26 PM > > To: Steve Davies; midcom > > Cc: Melinda Shore; Jonathan Rosenberg > > Subject: RE: [midcom] pre-midcom candidates - the Davies Critique > > > > > > Steve, > > > > Your point regarding "Stun and firewalls" is mistaken. The STUN > > requirement is that if there is a firewall, it let a response > > come in to > > a packet sent from an internal port. This is the default behavior of > > most "residential NAT/firewall", and it is also an optional > > behavior in > > many enterprise firewalls. Whether such a policy is deemed > > acceptable by > > the local IT manager is debatable -- there are pros and cons. > > > > -- Christian Huitema > > > > -----Original Message----- > > From: Steve Davies [mailto:sdavies@ridgewaysystems.com] > > Sent: Wednesday, October 31, 2001 12:57 PM > > To: 'midcom' > > Cc: 'Melinda Shore'; 'Jonathan Rosenberg' > > Subject: RE: [midcom] pre-midcom candidates - the Davies Critique > > > > (Apologies if you get this twice. The first attempt was too > > long for the > > mailing list so I've deleted the history.).... > > Naturally, I don't entirely agree with Jonathan's analysis. Here is > > mine: > > The Sen Proposal: > > ----------------- > > I don't see the Sen proposal as an adequate near-term/pre-midcom > > solution for two main reasons: > > (a) it requires changes to the protocol: > > ---------------------------------------- > > In order to make the Sen proposal work we are told that a new service > > tag must be incorporated in the SIP Register request and a > > new SIP Ping > > (keep-alive) method must be incorporated. Not only will this take time > > to implement in SIP but presumably we'll also need corresponding > > protocol changes for Megaco, MGCP, H.323, etc. Or is Midcom > > SIP-specific? > > (b) it requires behavioural changes to the client: > > -------------------------------------------------- > > It requires symmetric RTP and the continual transmission of > > RTP and RTCP > > packets to keep the NAT bindings open. While symmetric RTP > > may be a good > > thing, that doesn't imply all applications have constant > > bi-directional > > streams - think of 'broadcast' type applications. Also why should > > terminals be expected to turn off silence suppression? How > > are endpoints > > to know when and when not to make this behavioural change? > > Other weaknesses of the proposal include a requirement on terminals to > > signal to the SIP proxy when they are behind a NAT. It is not > > explained > > how they are supposed to know whether or not they are. > > Additionally, the > > use of random ports on the RTP Proxy makes it difficult to > > protect such > > a device with a regular filtering firewall. Such > > configurations would be > > required for an enterprise do-it-yourself solution(the > > enterprise is its > > own provider) and by service providers wanting to protect > > their networks > > and service from DoS attacks. > > Note that correction of all these shortcomings results in the same > > architecture and method outlined in the Davies proposal. > > The Rosenberg/STUN Proposal: > > ---------------------------- > > Whilst I acknowledge the STUN proposal provides a method to determine > > the type of NAT a terminal may be behind, I view the proposal as > > incomplete and potentially impractical candidate as a > > near-term/pre-midcom solution. > > a) Firewalls are everywhere: > > ---------------------------- > > Whenever a firewall is deployed in conjunction with a NAT, > > irrespective > > of the type of NAT, the net result is equivalent to what the > > STUN method > > describes as a Symmetric NAT. In the case of symmetric NATs, the > > Rosenberg proposal acknowledges that a media > > intermediary/relay (or RTP > > Proxy) is required. However, the STUN proposal doesn't inform us what > > the architecture and method are for making calls in this > > case, although > > Jonathan acknowledges in his email that there are three > > solutions - the > > Davies proposal, the Sen proposal and an unpublished STUN proposal. > > Firewalls are a fact of life in all enterprises connected to the > > internet. An ever-increasing number of users are installing > > firewalls in > > their homes as well. The majority of calls will require a media > > intermediary/RTP Proxy. In other words, VoIP providers will have to > > install media intermediaries from Day One of any service. Can you > > imagine the subscription scenario if they don't: > > Customer: 'Please may I subscribe to your service' > > Provider: 'Is your terminal behind a firewall?' > > Customer: 'Yes' > > Provider: 'Sorry our service won't work for you' or 'Yes, but please > > place your terminal outside the firewall' or 'Yes, but you > > can only call > > other people not behind a firewall or symmetric NAT'. > > This is not what the VoIP industry needs right now! > > b) Too early to optimise: > > ------------------------- > > The STUN proposal boils down to a port saving technique for VoIP > > providers. But in a nascent market its impractical to start > > with a port > > saving technique particularly when its unquantifiable how many ports a > > provider may save. What providers need is a solution that is > > deployable > > in all cases - that implies a media intermediary solution. Trying to > > combine a port saving technique in conjunction with a media > > intermediary > > solution will add complexity that will delay and stall the > > VoIP market. > > From a provider's perspective, this delay and additional testing could > > far outweigh any savings gained by requiring fewer media intermediary > > ports. > > c) Unproven: > > ------------ > > i) TIMEOUTS. When a user is behind a firewall or symmetric > > NAT, to avoid > > use of a media intermediary the terminal must invoke the STUN protocol > > on a call by call basis. The STUN protocol requires potentially > > significant timeouts to expire in order to determine whether media may > > go direct. What will this do to call setup times? > > ii) NETWORK BASED NATS. There may be cases where the terminal > > determines > > that the media may go direct, but in fact the media passes through > > network based NATs and the call will fail. This would typically happen > > at the provider boundary, because the provider uses some internal > > addressing scheme or when passing from IPv4 to IPv6 networks. The > > solution would be to place the STUN server on the remote side of those > > network based NATs, but this would have the consequence of tromboning > > the media via those network based NATs for 'provider-internal' calls, > > defeating the reason for STUN. Alternatively, multiple STUN servers > > would need to be deployed - one for each different NAT location, but > > that then poses the question of how a terminal would know which STUN > > server to use on a call-by-call basis. > > Davies proposal: > > ---------------- > > The Davies proposal is very midcom-like. The Proxy Extension > > Agent (PEA) > > is like a MIDDLEBOX and the Application Proxy (AP) is like a MIDCOM > > AGENT. The AP is responsible for getting publicly reachable transport > > addresses on the PEA for external calls and publishing those addresses > > in the protocol messages. > > The Davies proposal simplifies the security policy problem being > > grappled with by MIDCOM to a very simple static policy > > administered and > > controlled by the IT manager and implemented on existing > > firewalls. Just > > three static pinholes are required to be configured in the firewall. > > Furthermore, these pinholes are outbound pinholes(i.e. out from the > > enterprise). > > Jonathan writes that in the Davies draft there are issues to do with > > consistency with enterprise firewall policy, but this is > > unsubstantiated. When details of these issues are provided, we will be > > happy to discuss them. The Davies method is entirely consistent with > > enterprise firewall policy - it is similar to, but actually far more > > restrictive than the firewall policy that allows web browsing for > > example. The Davies proposal's policy has been vetted by service > > providers and is already in commercial deployments - we can > > only assume > > enterprises find it acceptable. > > As well as being midcom-like, the Davies method has many other > > significant advantages: > > * It provides a 100% solution. It will work anywhere no > > matter how many > > and what type and combination of firewalls and NATs there are. > > * No change is required to any of the protocols. It is not even > > necessary for endpoints to implement symmetric RTP. > > * The implementation can be made transparent to the endpoints or be > > implemented by them. > > * Enterprise or Service Provider deployments are possible. The PEA may > > be deployed within a service provider's network or within the > > DMZ of an > > enterprise's own service centre. > > * Passing through a media intermediary is seen as enhancing > > security and > > saving IP addresses. Hiding an enterprise IP address from the remote > > party (only the transport addresses of the PEA are published in > > messages) is seen as a benefit and enables the enterprise to use the > > same IP address used for other Internet traffic. > > * Service Providers see a benefit in handling the media > > through PEA for > > several reasons. It enables them to hide the transport addresses of > > their other service equipment. It provides them with a > > suitable point to > > implement wire-tapping (e.g.CALEA) - ITSPs in many countries are bound > > to provide such capabilities. It also provides them with a media QOS > > execution point and it provides suitable IPv4/IPv6 migration boundary > > points. > > Jonathan seeks to belittle the Davies proposal by likening it to RSIP. > > I'm not sure what the point is here. It is true that we have borrowed > > and learnt from many of the principles and techniques used within the > > Internet. That's why we have well known ports, outbound initiated > > connections, and TCP multiplexing, so it's not surprising the > > method is > > recognisable and architecturally looks similar to other > > protocols. What > > is unique, is the way in which this method combines the different > > Internet techniques together with the transport of real-time > > UDP streams > > without any tunneling overhead. > > In fact, the single disadvantage of the Davies proposal is that it > > requires media intermediaries, but no-one has devised a non-media > > intermediary solution that solves all of today's firewall and NAT > > deployments. In any case, media intermediaries are not of much concern > > to service providers because they will co-locate those intermediaries > > with their access equipment in their POPs. In due course, those > > intermediaries may even be implemented in the access routers or Midcom > > will obviate them. > > Pre-Midcom Recommendation: > > -------------------------- > > Jonathan writes that he wants to tackle the harder stuff, > > i.e. firewalls > > and symmetric NATs, later. The fact of the matter is that the Davies > > proposal has solved the harder stuff already. It is the > > Davies proposal > > that is the low-hanging fruit because it addresses 100% of deployments > > and it has working examples. Surely this is where a > > pre-midcom solution > > must start. A VoIP provider needs it from Day One because it is very > > likely some/many customers will have a firewall or symmetric > > NAT. If in > > time, providers are seeking more efficient deployments or are > > seeking to > > reduce costs, then the Davies solution is easily extended to > > incorporate > > a STUN-like method. But before embarking on this effort it > > would be wise > > to judge the market need and determine when MIDCOM will kick in. > > Steve Davies > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www1.ietf.org/mailman/listinfo/midcom > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Nov 1 13:51:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27487 for ; Thu, 1 Nov 2001 13:51:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA12848 for midcom-archive@odin.ietf.org; Thu, 1 Nov 2001 13:51:53 -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 NAA12806; Thu, 1 Nov 2001 13:49:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12777 for ; Thu, 1 Nov 2001 13:49:34 -0500 (EST) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27409 for ; Thu, 1 Nov 2001 13:49:27 -0500 (EST) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GM400EJXXGNOY@firewall.wcom.com> for midcom@ietf.org; Thu, 1 Nov 2001 18:46:00 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0GM400701XGG70@pmismtp02.wcomnet.com>; Thu, 01 Nov 2001 18:45:59 +0000 (GMT) Received: from rccc6131 ([166.35.225.46]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0GM4004GRXG70R@pmismtp02.wcomnet.com>; Thu, 01 Nov 2001 18:45:43 +0000 (GMT) Date: Thu, 01 Nov 2001 12:45:39 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] pre-midcom candidates In-reply-to: To: "'James Ho'" , bpenfield@acmepacket.com, bscott@ridgewaysystems.com, midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <000f01c16305$67aa87e0$2ee123a6@rccc6131.mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 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 This would work well for an isolated network (intranet or extranet) but when it is desired to allow anyone (Internet) access it would be infeasible to provide security associations to the world and probably impossible for many endpoints (From an interoperability standpoint between vendors)...It really depends on the scale of the solution (I like IPSec solutions myself). Also, IPSec doesnt provide security policy enforcement, as a firewall typically would on non-IPSec encapsulated packets, merely privacy. When you tunnel IPSec through a firewall from endpoints, unless the security associations are setup to be granular, the firewall cannot act on the packets inside the tunnel. Also not all firewalls allow IPSec (IP 50 and 51) the ability to pass through them. > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > James Ho > Sent: Thursday, November 01, 2001 11:25 AM > To: bpenfield@acmepacket.com; bscott@ridgewaysystems.com; > midcom@ietf.org > Subject: Re: [midcom] pre-midcom candidates > > > Why could'nt tunnel-mode IPsec be used beween an IPsec end-point in > the enterprise and another in the SP network to tunnel H.323/SIP > traffic across firewalls? The auth/integrity checking within ESP > with null encryption should allow for a secure tunnel improving > enterprise IT confidence. Plus its a standard approach vs. the > "proprietary' approaches proposed. To address NAT issues, the > internal IPsec end-point could have a public IP address. > > I don;t performance/latency will be an issue as IP storage folks > are considering tunnel-mode IPsec to be a mandatory requirement > for all IP storage protocols (i.e. iSCSI, FCIP, etc). > > Saqib > > >From: "Bob Penfield" > >To: "Barry Scott" , "'James Ho'" > >, > >Subject: Re: [midcom] pre-midcom candidates > >Date: Thu, 1 Nov 2001 11:29:46 -0500 > > > >What percentage of NAT/FW are symmetric as opposed to full-cone as > >described > >in the STUN proposal? There is some debate whether or not the interim > >solution needs to address the symmetric NAT problem. If the > great majority > >of existing FW/NAT are symmetric, we probably need to include it now. > > > >(-:bob > > > >Robert F. Penfield > >Chief Software Architect > >Acme Packet, Inc. > >130 New Boston Street > >Woburn, MA 01801 > >bpenfield@acmepacket.com > > > >----- Original Message ----- > >From: "Barry Scott" > >To: "'James Ho'" ; > >Sent: Thursday, November 01, 2001 9:58 AM > >Subject: RE: [midcom] pre-midcom candidates > > > > > > > The policy we need turns out to be the default for many > > > enterprises already. > > > > > > Typical behavour is to prevent UDP from the outside > > > to get inside. But once a UDP packet from the inside > > > is sent to the outside the firewall will pinhole itself > > > to allow return traffic. After a period of inactivity > > > the firewall will close the pinhole, for example after > > > 45 seconds. > > > > > > BArry > > > > > > -----Original Message----- > > > From: James Ho [mailto:jamesho37@hotmail.com] > > > Sent: 31 October 2001 22:20 > > > To: midcom@ietf.org > > > Subject: RE: [midcom] pre-midcom candidates > > > > > > > > > As I understand it, the Davies proposal requires an open > > > UDP port on the firewall for media traversal. I can't think > > > of many/any enterprises being willing to implement such a > > > firewall policy. Or maybe my understanding is faulty?? > > > > > > james > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp > > > > > > > > > _______________________________________________ > > > midcom mailing list > > > midcom@ietf.org > > > http://www1.ietf.org/mailman/listinfo/midcom > > > > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Nov 1 15:59: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 ESMTP id PAA00366 for ; Thu, 1 Nov 2001 15:59:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA16980 for midcom-archive@odin.ietf.org; Thu, 1 Nov 2001 15:59:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16912; Thu, 1 Nov 2001 15:54: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 PAA16881 for ; Thu, 1 Nov 2001 15:54:37 -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 ESMTP id PAA00206 for ; Thu, 1 Nov 2001 15:54:31 -0500 (EST) Received: from asimu-u5.cisco.com (asimu-u5.cisco.com [128.107.162.97]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fA1Ks9X27072; Thu, 1 Nov 2001 12:54:09 -0800 (PST) Received: from cisco.com (localhost [127.0.0.1]) by asimu-u5.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA26170; Thu, 1 Nov 2001 12:54:04 -0800 (PST) Message-ID: <3BE1B66C.1635A2E3@cisco.com> Date: Thu, 01 Nov 2001 12:54:04 -0800 From: Adina Simu Organization: Cisco Systems X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: christopher.a.martin@wcom.com CC: "'James Ho'" , bpenfield@acmepacket.com, bscott@ridgewaysystems.com, midcom@ietf.org Subject: Re: [midcom] pre-midcom candidates References: <000f01c16305$67aa87e0$2ee123a6@rccc6131.mcit.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 IPsec itself has big problems with NATs - NAPTs in particular (as probably all of you know already :)). -Adina "Christopher A. Martin" wrote: > > This would work well for an isolated network (intranet or extranet) but when > it is desired to allow anyone (Internet) access it would be infeasible to > provide security associations to the world and probably impossible for many > endpoints (From an interoperability standpoint between vendors)...It really > depends on the scale of the solution (I like IPSec solutions myself). > > Also, IPSec doesnt provide security policy enforcement, as a firewall > typically would on non-IPSec encapsulated packets, merely privacy. When you > tunnel IPSec through a firewall from endpoints, unless the security > associations are setup to be granular, the firewall cannot act on the > packets inside the tunnel. > > Also not all firewalls allow IPSec (IP 50 and 51) the ability to pass > through them. > > > -----Original Message----- > > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > > James Ho > > Sent: Thursday, November 01, 2001 11:25 AM > > To: bpenfield@acmepacket.com; bscott@ridgewaysystems.com; > > midcom@ietf.org > > Subject: Re: [midcom] pre-midcom candidates > > > > > > Why could'nt tunnel-mode IPsec be used beween an IPsec end-point in > > the enterprise and another in the SP network to tunnel H.323/SIP > > traffic across firewalls? The auth/integrity checking within ESP > > with null encryption should allow for a secure tunnel improving > > enterprise IT confidence. Plus its a standard approach vs. the > > "proprietary' approaches proposed. To address NAT issues, the > > internal IPsec end-point could have a public IP address. > > > > I don;t performance/latency will be an issue as IP storage folks > > are considering tunnel-mode IPsec to be a mandatory requirement > > for all IP storage protocols (i.e. iSCSI, FCIP, etc). > > > > Saqib > > > > >From: "Bob Penfield" > > >To: "Barry Scott" , "'James Ho'" > > >, > > >Subject: Re: [midcom] pre-midcom candidates > > >Date: Thu, 1 Nov 2001 11:29:46 -0500 > > > > > >What percentage of NAT/FW are symmetric as opposed to full-cone as > > >described > > >in the STUN proposal? There is some debate whether or not the interim > > >solution needs to address the symmetric NAT problem. If the > > great majority > > >of existing FW/NAT are symmetric, we probably need to include it now. > > > > > >(-:bob > > > > > >Robert F. Penfield > > >Chief Software Architect > > >Acme Packet, Inc. > > >130 New Boston Street > > >Woburn, MA 01801 > > >bpenfield@acmepacket.com > > > > > >----- Original Message ----- > > >From: "Barry Scott" > > >To: "'James Ho'" ; > > >Sent: Thursday, November 01, 2001 9:58 AM > > >Subject: RE: [midcom] pre-midcom candidates > > > > > > > > > > The policy we need turns out to be the default for many > > > > enterprises already. > > > > > > > > Typical behavour is to prevent UDP from the outside > > > > to get inside. But once a UDP packet from the inside > > > > is sent to the outside the firewall will pinhole itself > > > > to allow return traffic. After a period of inactivity > > > > the firewall will close the pinhole, for example after > > > > 45 seconds. > > > > > > > > BArry > > > > > > > > -----Original Message----- > > > > From: James Ho [mailto:jamesho37@hotmail.com] > > > > Sent: 31 October 2001 22:20 > > > > To: midcom@ietf.org > > > > Subject: RE: [midcom] pre-midcom candidates > > > > > > > > > > > > As I understand it, the Davies proposal requires an open > > > > UDP port on the firewall for media traversal. I can't think > > > > of many/any enterprises being willing to implement such a > > > > firewall policy. Or maybe my understanding is faulty?? > > > > > > > > james > > > > > > > > _________________________________________________________________ > > > > Get your FREE download of MSN Explorer at > > >http://explorer.msn.com/intl.asp > > > > > > > > > > > > _______________________________________________ > > > > midcom mailing list > > > > midcom@ietf.org > > > > http://www1.ietf.org/mailman/listinfo/midcom > > > > > > > > > > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at > > http://explorer.msn.com/intl.asp > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www1.ietf.org/mailman/listinfo/midcom > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Nov 1 16:29:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01073 for ; Thu, 1 Nov 2001 16:29:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA18207 for midcom-archive@odin.ietf.org; Thu, 1 Nov 2001 16:29: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 QAA18058; Thu, 1 Nov 2001 16:25:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17978 for ; Thu, 1 Nov 2001 16:25:49 -0500 (EST) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00940 for ; Thu, 1 Nov 2001 16:25:43 -0500 (EST) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA01549 for ; Thu, 1 Nov 2001 15:25:16 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Thu, 1 Nov 2001 15:18:19 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Nov 2001 15:24:24 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F29D@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Steve Davies'" , "'midcom'" Cc: "'Melinda Shore'" , "'Jonathan Rosenberg'" Subject: RE: [midcom] pre-midcom candidates - the Davies Critique Date: Thu, 1 Nov 2001 15:24:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1631B.96490840" X-Orig: Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1631B.96490840 Content-Type: text/plain; charset="iso-8859-1" Comments inline. -----Original Message----- From: Steve Davies [mailto:sdavies@ridgewaysystems.com] Sent: Wednesday, October 31, 2001 2:57 PM To: 'midcom' Cc: 'Melinda Shore'; 'Jonathan Rosenberg' Subject: RE: [midcom] pre-midcom candidates - the Davies Critique (Apologies if you get this twice. The first attempt was too long for the mailing list so I've deleted the history.).... Naturally, I don't entirely agree with Jonathan's analysis. Here is mine: The Sen Proposal: ----------------- I don't see the Sen proposal as an adequate near-term/pre-midcom solution for two main reasons: [SS] The solution is already in live deployment in some service provider networks! (a) it requires changes to the protocol: ---------------------------------------- In order to make the Sen proposal work we are told that a new service tag must be incorporated in the SIP Register request and a new SIP Ping (keep-alive) method must be incorporated. Not only will this take time to implement in SIP but presumably we'll also need corresponding protocol changes for Megaco, MGCP, H.323, etc. Or is Midcom SIP-specific? [SS] The Proxy-Require option tag is only what is required. You need to enable the Proxy distinguish between the cases when it should and should not send messages to the source address/port of the received packet. The Ping method is optional, Register refreshes can be used instead. The drawback of the latter is that it hits the Registrar (at least once every minute) unnecesarily. We tried that & ran into performance problems which made us switch to a more lightweight mechanism. Yes, the signaling solution depicted in the draft is SIP-specific. (b) it requires behavioural changes to the client: -------------------------------------------------- It requires symmetric RTP and the continual transmission of RTP and RTCP packets to keep the NAT bindings open. While symmetric RTP may be a good thing, that doesn't imply all applications have constant bi-directional streams - think of 'broadcast' type applications. Also why should terminals be expected to turn off silence suppression? How are endpoints to know when and when not to make this behavioural change? [SS] The "Symmetric RTP" that we use is simply receive packets in the same port that you send packets from. This is easily configurable in amost all existing clients. To keep the media path through the FW/NAT open, the client is required to send out RTP/UDP packets voluntarily only when the media stream is muted. These packets can be silence packets (which are generated by many codecs for comfort noise) or empty UDP packets. Additionally, the use of random ports on the RTP Proxy makes it difficult to protect such a device with a regular filtering firewall. Such configurations would be required for an enterprise do-it-yourself solution(the enterprise is its own provider) and by service providers wanting to protect their networks and service from DoS attacks. [SS] This should not be a problem for the Enterprise-do-it-yourself , because they would typically have to trust packets coming from behind their own firewall/NAT! In either case, the FW would only have to allow known addresses/ports from the Enterprise side. Sanjoy ------_=_NextPart_001_01C1631B.96490840 Content-Type: text/html; charset="iso-8859-1" RE: [midcom] pre-midcom candidates - the Davies Critique

Comments inline.

-----Original Message-----
From: Steve Davies [mailto:sdavies@ridgewaysystems.com]
Sent: Wednesday, October 31, 2001 2:57 PM
To: 'midcom'
Cc: 'Melinda Shore'; 'Jonathan Rosenberg'
Subject: RE: [midcom] pre-midcom candidates - the Davies Critique

(Apologies if you get this twice. The first attempt was too long for the mailing list so I've deleted the history.)....

Naturally, I don't entirely agree with Jonathan's analysis. Here is mine:

The Sen Proposal:
-----------------
I don't see the Sen proposal as an adequate near-term/pre-midcom solution for two main reasons:

[SS] The solution is already in live deployment in some service provider networks!

(a) it requires changes to the protocol:
----------------------------------------
In order to make the Sen proposal work we are told that a new service tag must be incorporated in the SIP Register request and a new SIP Ping (keep-alive) method must be incorporated. Not only will this take time to implement in SIP but presumably we'll also need corresponding protocol changes for Megaco, MGCP, H.323, etc. Or is Midcom SIP-specific?

[SS] The Proxy-Require option tag is only what is required. You need to enable the Proxy distinguish between the cases when it should and should not send messages to the source address/port of the received packet. The Ping method is optional, Register refreshes can be used instead. The drawback of the latter is that it hits the Registrar (at least once every minute) unnecesarily. We tried that & ran into performance problems which made us switch to a more lightweight mechanism.

Yes, the signaling solution depicted in the draft is SIP-specific.

(b) it requires behavioural changes to the client:
--------------------------------------------------
It requires symmetric RTP and the continual transmission of RTP and RTCP packets to keep the NAT bindings open. While symmetric RTP may be a good thing, that doesn't imply all applications have constant bi-directional streams - think of 'broadcast' type applications. Also why should terminals be expected to turn off silence suppression? How are endpoints to know when and when not to make this behavioural change?

[SS] The "Symmetric RTP" that we use is simply receive packets in the same port that you send packets from. This is easily configurable in amost all existing clients.  To keep the media path through the FW/NAT open, the client is required to send out RTP/UDP packets voluntarily only when the media stream is muted. These packets can be silence packets (which are generated by many codecs for comfort noise) or empty UDP packets.

  Additionally, the use of random ports on the RTP Proxy makes it difficult to protect such a device with a regular filtering firewall. Such configurations would be required for an enterprise do-it-yourself solution(the enterprise is its own provider) and by service providers wanting to protect their networks and service from DoS attacks.

[SS] This should not be a problem for the Enterprise-do-it-yourself , because they would typically have to trust packets coming from behind their own firewall/NAT! In either case, the FW would only have to allow known addresses/ports from the Enterprise side.

Sanjoy

------_=_NextPart_001_01C1631B.96490840-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Nov 2 00:33:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10939 for ; Fri, 2 Nov 2001 00:33:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA29316 for midcom-archive@odin.ietf.org; Fri, 2 Nov 2001 00:33:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA29272; Fri, 2 Nov 2001 00:30: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 AAA29235 for ; Fri, 2 Nov 2001 00:30:49 -0500 (EST) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10870 for ; Fri, 2 Nov 2001 00:30:47 -0500 (EST) Received: from mduffy (10.1.1.254 [10.1.1.254]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 49ZFCT1J; Fri, 2 Nov 2001 00:30:18 -0500 Message-Id: <3.0.5.32.20011102002139.00820510@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 02 Nov 2001 00:21:39 -0500 To: Melinda Shore , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Current status In-Reply-To: <5.1.0.14.0.20011031174517.00a5b0c0@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org >Framework: There have been *no* comments on the recent revision >of the framework draft. I'm not sure I want to start WG last call >on it until I have some sense of whether or not more than a few >people have given it a good going-over already. Have you? I have some minor documentation comments I'll send separately. More substantively, what if any resolution to the topology question can we reach? This is both a technical and political question. Whatever the resolution surely the framework should reflect it. The framework draft basically decides not to address this (section 5.0 first paragraph, and section 9 first paragraph). We have the Aoun/Sen, Penfield, and Molitor drafts from August that seem to support about that same conclusion: the ability to support complex topologies is basically limited by the topology knowledge the agent has available. We have the in-and-out proposal from Scott which allows some use of topology knowledge the middlebox might have, but does not address middlebox discovery by agents. And then there is the "friendly" RSVP-like proposal from Melinda which seems to address the topology and discovery questions although it lies somewhat "outside the box" of the framework and requirements work to date in the wg. - Mark P.S. apologies in advance for any mangling I have done in attempting to summarize the drafts in one sentence each. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Nov 2 00:33:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10934 for ; Fri, 2 Nov 2001 00:33:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA29302 for midcom-archive@odin.ietf.org; Fri, 2 Nov 2001 00: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 AAA29233; Fri, 2 Nov 2001 00: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 AAA29202 for ; Fri, 2 Nov 2001 00:30:47 -0500 (EST) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10863 for ; Fri, 2 Nov 2001 00:30:45 -0500 (EST) Received: from mduffy (10.1.1.254 [10.1.1.254]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 49ZFCT1G; Fri, 2 Nov 2001 00:30:15 -0500 Message-Id: <3.0.5.32.20011102002146.008f6a90@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 02 Nov 2001 00:21:46 -0500 To: Pyda Srisuresh , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Rev4 of MIDCOM Architecture & framework document In-Reply-To: <20011017121426.70434.qmail@web13802.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Thank you Suresh, here are my comments. These are just suggestions on the document, not I think on the fundamental concepts. -- Mark. Section 2.15 -- definition of "Ruleset". I recommend we remove the second paragraph: Ruleset specifies the dynamic resources (i.e., Filter Specs, Action Specs, Ruleset type, Timeout values etc.) that maybe communicated through the MIDCOM protocol. I don't think it adds much to the definition, and it introduces another new undefined term ("resources"). There was some discussion of removing this on the list 4 Oct. Section 6.0 -- policy server. In the third paragraph it states The policy server acts in an advisory capacity to a middlebox to authorize or terminate authorization for an agent to gain connectivity to the middlebox. The primary objective of a policy I think "gain connectivity to the middlebox" is a fairly imprecise wording. Section 2.9 (policy server definition) has more/better description than this section 6.0. Perhaps some of that can be moved here and replace some of 6.0. BTW my understanding, and I can read this into the section 2.9 description but it is not unambiguously stated there, that the policy server may govern which agents may establish midcom sessions with the middlebox *and also* restrict what Rulesets a given agent may manipulate. No? Perhaps we can clarify that. Section 6.2 -- registration. The first paragraph explains that registration is different than establishing a session. The phrase "transport session" is used several times in this paragraph. I suggest that the first two uses should be replaced with the recently defined term "Midcom session". Section 6.2. The third paragraph seems confusing. Also, it discusses either the agent or the middlebox initiating the midcom session. My understanding from the requirements discussion etc. is that we have come around to only the agent initiating the session. I suggest modifying the paragraph as follows: The MIDCOM agent profile may be pre-configured on the middlebox while provisioning the middlebox function. Thereafter, the agent may choose to initiate a Midcom session prior to any data traffic. Alternatively, it may choose to initiate a Midcom session only upon noticing the application specific traffic. Section 6.2. The 4th paragraph discusses "Coupling MIDCOM agents with the middlebox ruleset". I'm not sure what that coupling refers to. Can we clarify this? Section 6.2. The seventh paragraph is confusing, and again contains the concept of the middlebox initiating the midcom session. Since the main purpose of this paragraph (I think) is to point out that the agent information may be provisioned into a policy server rather than the middlebox, and we've said that above, I suggest just omitting this paragraph. Section 6.2, 8th paragraph. The first seven lines here are about midcom session disconnection and have nothing to do with registration/deregistration. Since they cover material already presented in section 4, I suggest deleting them. Section 11-security considerations. The first paragraph points out some deleterious effects of middleboxes on security protocols. The second paragraph seems to state that midcom can fix all this because the middlebox will no longer need to inspect or modify data. The text should acknowledge that the midcom model does not help with the problem of NAT breaking IPsec since in this case the middlebox still modifies data that matters. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Nov 2 02:33:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27335 for ; Fri, 2 Nov 2001 02:33:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA09087 for midcom-archive@odin.ietf.org; Fri, 2 Nov 2001 02:33:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09069; Fri, 2 Nov 2001 02:31:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09039 for ; Fri, 2 Nov 2001 02:31:15 -0500 (EST) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27328 for ; Fri, 2 Nov 2001 02:31:13 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA27TQb7002675; Fri, 2 Nov 2001 02:29:26 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Nov 2001 02:30:42 -0500 Message-ID: From: Jonathan Rosenberg To: "'James Ho'" , bpenfield@acmepacket.com, bscott@ridgewaysystems.com, midcom@ietf.org Subject: RE: [midcom] pre-midcom candidates Date: Fri, 2 Nov 2001 02:30:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: James Ho [mailto:jamesho37@hotmail.com] > Sent: Thursday, November 01, 2001 12:25 PM > To: bpenfield@acmepacket.com; bscott@ridgewaysystems.com; > midcom@ietf.org > Subject: Re: [midcom] pre-midcom candidates > > > Why could'nt tunnel-mode IPsec be used beween an IPsec end-point in > the enterprise and another in the SP network to tunnel H.323/SIP > traffic across firewalls? The auth/integrity checking within ESP > with null encryption should allow for a secure tunnel improving > enterprise IT confidence. Plus its a standard approach vs. the > "proprietary' approaches proposed. To address NAT issues, the > internal IPsec end-point could have a public IP address. Indeed, it could. In fact, any number of alternate VPN solutions could be used. I actually get through my nat at home by using a Microsoft VPN to my corporate network where our proxies and stuff run. The Davies approach is another form of vpn, if you think about it. All of these suffer from the problems of triangle routed media through the service provider, resulting in the expense of double-erlang bandwidth provisioning, and high latencies, that I have documented. The point I have been making, and the point I made continuously during the informal get together at IETF 51, was that if you are willing to accept these penalties, there are many VPN solutions today. They have their own issues in terms of compliance with enterprise firewall policy, but thats another issue I will comment on separately. What we need is a solution that does not suffer these problems, and that is what stun is offering. - Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > > Saqib > > >From: "Bob Penfield" > >To: "Barry Scott" , "'James Ho'" > >, > >Subject: Re: [midcom] pre-midcom candidates > >Date: Thu, 1 Nov 2001 11:29:46 -0500 > > > >What percentage of NAT/FW are symmetric as opposed to full-cone as > >described > >in the STUN proposal? There is some debate whether or not the interim > >solution needs to address the symmetric NAT problem. If the > great majority > >of existing FW/NAT are symmetric, we probably need to include it now. > > > >(-:bob > > > >Robert F. Penfield > >Chief Software Architect > >Acme Packet, Inc. > >130 New Boston Street > >Woburn, MA 01801 > >bpenfield@acmepacket.com > > > >----- Original Message ----- > >From: "Barry Scott" > >To: "'James Ho'" ; > >Sent: Thursday, November 01, 2001 9:58 AM > >Subject: RE: [midcom] pre-midcom candidates > > > > > > > The policy we need turns out to be the default for many > > > enterprises already. > > > > > > Typical behavour is to prevent UDP from the outside > > > to get inside. But once a UDP packet from the inside > > > is sent to the outside the firewall will pinhole itself > > > to allow return traffic. After a period of inactivity > > > the firewall will close the pinhole, for example after > > > 45 seconds. > > > > > > BArry > > > > > > -----Original Message----- > > > From: James Ho [mailto:jamesho37@hotmail.com] > > > Sent: 31 October 2001 22:20 > > > To: midcom@ietf.org > > > Subject: RE: [midcom] pre-midcom candidates > > > > > > > > > As I understand it, the Davies proposal requires an open > > > UDP port on the firewall for media traversal. I can't think > > > of many/any enterprises being willing to implement such a > > > firewall policy. Or maybe my understanding is faulty?? > > > > > > james > > > > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp > > > > > > > > > _______________________________________________ > > > midcom mailing list > > > midcom@ietf.org > > > http://www1.ietf.org/mailman/listinfo/midcom > > > > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Nov 2 02:39: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 ESMTP id CAA27360 for ; Fri, 2 Nov 2001 02:39:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA09166 for midcom-archive@odin.ietf.org; Fri, 2 Nov 2001 02:39: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 CAA09142; Fri, 2 Nov 2001 02:35: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 CAA09111 for ; Fri, 2 Nov 2001 02:35:56 -0500 (EST) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27351 for ; Fri, 2 Nov 2001 02:35:52 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA27Y6b7002695; Fri, 2 Nov 2001 02:34:06 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Nov 2001 02:35:22 -0500 Message-ID: From: Jonathan Rosenberg To: "'christopher.a.martin@wcom.com'" , "'James Ho'" , bpenfield@acmepacket.com, bscott@ridgewaysystems.com, midcom@ietf.org Subject: RE: [midcom] pre-midcom candidates Date: Fri, 2 Nov 2001 02:35:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > -----Original Message----- > From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] > Sent: Thursday, November 01, 2001 1:46 PM > To: 'James Ho'; bpenfield@acmepacket.com; bscott@ridgewaysystems.com; > midcom@ietf.org > Subject: RE: [midcom] pre-midcom candidates > > > This would work well for an isolated network (intranet or > extranet) but when > it is desired to allow anyone (Internet) access it would be > infeasible to > provide security associations to the world Well, one need not do it to the world. Presumably, the VoIP provider would offer this service to its customers. Then, it only need worry about offering ip addresses to the customers it has actively online. > Also, IPSec doesnt provide security policy enforcement, as a firewall > typically would on non-IPSec encapsulated packets, merely > privacy. When you > tunnel IPSec through a firewall from endpoints, unless the security > associations are setup to be granular, the firewall cannot act on the > packets inside the tunnel. No, they can't. Thats why it works. But thats also the problem shared by all the vpn and tunneling solutions; they ultimately work since they help bypass enterprise firewall policies that might exist. Stun doesn't do tunneling; if the firewall disallows outbound UDP then you can't send outbound UDP. It therefore insures that enterprise firewall policy continues to be obeyed. > Also not all firewalls allow IPSec (IP 50 and 51) the ability to pass > through them. Pick your favorite vpn. Others get through and work. My favorite remains RFC3093, which will traverse almost all firewalls and nats. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Nov 2 05:48:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29037 for ; Fri, 2 Nov 2001 05:48:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA14063 for midcom-archive@odin.ietf.org; Fri, 2 Nov 2001 05:48:34 -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 FAA14006; Fri, 2 Nov 2001 05:45:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13977 for ; Fri, 2 Nov 2001 05:45:41 -0500 (EST) Received: from rhenium (rhenium.btinternet.com [194.73.73.93]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29002 for ; Fri, 2 Nov 2001 05:45:32 -0500 (EST) Received: from [213.122.14.30] (helo=tkw) by rhenium with smtp (Exim 3.22 #6) id 15zbpE-0003dn-00; Fri, 02 Nov 2001 10:45:25 +0000 Message-ID: <004101c16387$c6786bc0$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" , , "'James Ho'" , , , References: Subject: Re: [midcom] pre-midcom candidates Date: Fri, 2 Nov 2001 10:18:50 -0000 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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 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, By quoting RFC 3093 as your favourite VPN solution you are really saying that a standard VPN solution is not appropriate for the job! Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Jonathan Rosenberg To: ; 'James Ho' ; ; ; Sent: 02 November 2001 07:35 Subject: RE: [midcom] pre-midcom candidates > > > > > > -----Original Message----- > > From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] > > Sent: Thursday, November 01, 2001 1:46 PM > > To: 'James Ho'; bpenfield@acmepacket.com; bscott@ridgewaysystems.com; > > midcom@ietf.org > > Subject: RE: [midcom] pre-midcom candidates > > > > > > This would work well for an isolated network (intranet or > > extranet) but when > > it is desired to allow anyone (Internet) access it would be > > infeasible to > > provide security associations to the world > > Well, one need not do it to the world. Presumably, the VoIP provider would > offer this service to its customers. Then, it only need worry about offering > ip addresses to the customers it has actively online. > > > > Also, IPSec doesnt provide security policy enforcement, as a firewall > > typically would on non-IPSec encapsulated packets, merely > > privacy. When you > > tunnel IPSec through a firewall from endpoints, unless the security > > associations are setup to be granular, the firewall cannot act on the > > packets inside the tunnel. > > No, they can't. Thats why it works. But thats also the problem shared by all > the vpn and tunneling solutions; they ultimately work since they help bypass > enterprise firewall policies that might exist. > > Stun doesn't do tunneling; if the firewall disallows outbound UDP then you > can't send outbound UDP. It therefore insures that enterprise firewall > policy continues to be obeyed. > > > Also not all firewalls allow IPSec (IP 50 and 51) the ability to pass > > through them. > > Pick your favorite vpn. Others get through and work. My favorite remains > RFC3093, which will traverse almost all firewalls and nats. > > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Nov 2 10:21: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 ESMTP id KAA07572 for ; Fri, 2 Nov 2001 10:21:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19789 for midcom-archive@odin.ietf.org; Fri, 2 Nov 2001 10:21: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 KAA19732; Fri, 2 Nov 2001 10:17: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 KAA19703 for ; Fri, 2 Nov 2001 10:17:30 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07347 for ; Fri, 2 Nov 2001 10:17:27 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.04) id A90AFE90146; Fri, 02 Nov 2001 10:17:30 -0500 Message-ID: <00d601c163b1$08578840$2300000a@acmepacket.com> From: "Bob Penfield" To: "midcom" References: Subject: Re: [midcom] pre-midcom candidates Date: Fri, 2 Nov 2001 10:14:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi all, I just want to throw my hat into the ring as a supporter of the STUN proposal. It is very simple and will be relatively easy to implement directly in endpoints. It requires no state in the server side. It adheres to the security policy of the firewall/NAT owner. With STUN as a basic tool, more complex solutions can be developed. It could even be used to implement much of the Davies proposal. I do think we need to address the symmetric NAT problem soon. The Sen proposal seems too narrow in its focus on SIP and RTP. It also includes a midcom-like component in the protocol between the SIP element and the RTP proxy. To standardize this approach we would need to standardize the RTP proxy control protocol and we would virtually have midcom. The RTP proxy is just a specialized NAT middlebox. There are number of things I find troubling about the Davies proposal: - The tunneling of the signaling through the firewall verges on subverting the security policy of the firewall owner. As others have stated, existing VPN methods can do this today. I also think that outbound TCP connections for signaling can work in most cases. - The protocol that would be required to implement this solution seems to be too complex. I counted 12 methods. It seems to be as complex, if not more so, than midcom will need to be. How long will it take to devise and standardize it? Based on the claims of the draft, Ridgeway has devised this protocol, but have they published the details? Given the complexity, it will be more difficult and costly to develop endpoints that support it. Given that, intermediate devices will be needed until all the endpoints support it, which again increases the cost of deploying VOIP and other applications. I think STUN is the best alternative for an easy, quick, and cost effective solution for NAT/FW that will allow for wider deployment of VOIP and other applications. It provides an interim solution until midcom is completed and also is useful in the long term for scenarios where midcom is not appropriate. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Nov 2 10:37: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 ESMTP id KAA08112 for ; Fri, 2 Nov 2001 10:37:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA20399 for midcom-archive@odin.ietf.org; Fri, 2 Nov 2001 10:37:37 -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 KAA20113; Fri, 2 Nov 2001 10:30: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 KAA20084 for ; Fri, 2 Nov 2001 10:30:22 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07918 for ; Fri, 2 Nov 2001 10:30:19 -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.11.3/8.9.1) with ESMTP id fA2FTqT23192; Fri, 2 Nov 2001 07:29:52 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABV23867; Fri, 2 Nov 2001 07:29:22 -0800 (PST) Message-Id: <5.1.0.14.0.20011102102741.00a5dec0@mira-sjc5-4.cisco.com> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 02 Nov 2001 10:30:50 -0500 To: Mark Duffy , midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Current status In-Reply-To: <3.0.5.32.20011102002139.00820510@email.quarrytech.com> References: <5.1.0.14.0.20011031174517.00a5b0c0@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:21 AM 11/2/01 -0500, Mark Duffy wrote: >The framework draft basically decides not to address this (section 5.0 >first paragraph, and section 9 first paragraph). We have the Aoun/Sen, >Penfield, and Molitor drafts from August that seem to support about that >same conclusion: the ability to support complex topologies is basically >limited by the topology knowledge the agent has available. The guidance from above right now seems to be "punt." This is likely to come up during the rechartering discussions; more on that later. In the meantime, many many many thanks to those who have gone through the framework document and provided feedback. We need to get this thing closed. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Nov 2 11:03:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08797 for ; Fri, 2 Nov 2001 11:03:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21258 for midcom-archive@odin.ietf.org; Fri, 2 Nov 2001 11:03:27 -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 LAA21031; Fri, 2 Nov 2001 11:00:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20997 for ; Fri, 2 Nov 2001 11:00:40 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08673 for ; Fri, 2 Nov 2001 11:00:37 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.04) id A3243E690146; Fri, 02 Nov 2001 11:00:36 -0500 Message-ID: <017501c163b7$0b325ee0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Mark Duffy" , , "Melinda Shore" References: <5.1.0.14.0.20011031174517.00a5b0c0@mira-sjc5-4.cisco.com> <5.1.0.14.0.20011102102741.00a5dec0@mira-sjc5-4.cisco.com> Subject: Re: [midcom] Current status Date: Fri, 2 Nov 2001 10:57:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Mark & Melinda, I am satisfied with our current requirement (R82) which does not preclude additional information/criteria in the filtering rules. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Melinda Shore" To: "Mark Duffy" ; Sent: Friday, November 02, 2001 10:30 AM Subject: Re: [midcom] Current status > At 12:21 AM 11/2/01 -0500, Mark Duffy wrote: > >The framework draft basically decides not to address this (section 5.0 > >first paragraph, and section 9 first paragraph). We have the Aoun/Sen, > >Penfield, and Molitor drafts from August that seem to support about that > >same conclusion: the ability to support complex topologies is basically > >limited by the topology knowledge the agent has available. > > The guidance from above right now seems to be "punt." This is > likely to come up during the rechartering discussions; more on > that later. > > In the meantime, many many many thanks to those who have gone > through the framework document and provided feedback. We need > to get this thing closed. > > Melinda > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Nov 2 11:35:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10650 for ; Fri, 2 Nov 2001 11:35:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22510 for midcom-archive@odin.ietf.org; Fri, 2 Nov 2001 11:35: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 LAA22396; Fri, 2 Nov 2001 11:32: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 LAA22370 for ; Fri, 2 Nov 2001 11:32:35 -0500 (EST) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10418 for ; Fri, 2 Nov 2001 11:32:32 -0500 (EST) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 49ZFC4QK; Fri, 2 Nov 2001 11:32:04 -0500 Message-Id: <3.0.5.32.20011102113046.007bee20@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 02 Nov 2001 11:30:46 -0500 To: "Bob Penfield" , , "Melinda Shore" From: Mark Duffy Subject: Re: [midcom] Current status In-Reply-To: <017501c163b7$0b325ee0$2300000a@acmepacket.com> References: <5.1.0.14.0.20011031174517.00a5b0c0@mira-sjc5-4.cisco.com> <5.1.0.14.0.20011102102741.00a5dec0@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi Bob, R82 makes the ruleset extensible. I think your point is that this allows extension to specify interfaces/realms/in/out/etc. Of course that does not help the agent with knowing what middleboxes are there and which to talk to. AFAIK discovery has never been in the charter and Melinda's message below seems to confirm this now. Ok with me for the time being, I just wanted to verify that this was still the case, as it was not abundantly obvious to me after we had the whole "topology issue" going on. :-) -Mark At 10:57 AM 11/2/01 -0500, Bob Penfield wrote: >Mark & Melinda, > >I am satisfied with our current requirement (R82) which does not preclude >additional information/criteria in the filtering rules. > >cheers, >(-:bob ... >----- Original Message ----- >From: "Melinda Shore" >To: "Mark Duffy" ; >Sent: Friday, November 02, 2001 10:30 AM >Subject: Re: [midcom] Current status > > >> At 12:21 AM 11/2/01 -0500, Mark Duffy wrote: >> >The framework draft basically decides not to address this (section 5.0 >> >first paragraph, and section 9 first paragraph). We have the Aoun/Sen, >> >Penfield, and Molitor drafts from August that seem to support about that >> >same conclusion: the ability to support complex topologies is basically >> >limited by the topology knowledge the agent has available. >> >> The guidance from above right now seems to be "punt." This is >> likely to come up during the rechartering discussions; more on >> that later. >> >> In the meantime, many many many thanks to those who have gone >> through the framework document and provided feedback. We need >> to get this thing closed. >> >> Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Nov 2 12:34:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12587 for ; Fri, 2 Nov 2001 12:34:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA24970 for midcom-archive@odin.ietf.org; Fri, 2 Nov 2001 12:34: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 MAA24589; Fri, 2 Nov 2001 12:28:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24538 for ; Fri, 2 Nov 2001 12:28:15 -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 ESMTP id MAA12410 for ; Fri, 2 Nov 2001 12:28:11 -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.11.3/8.9.1) with ESMTP id fA2HRgT20578; Fri, 2 Nov 2001 09:27:43 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABV26918; Fri, 2 Nov 2001 09:27:13 -0800 (PST) Message-Id: <5.1.0.14.0.20011102122448.00a65910@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 02 Nov 2001 12:29:58 -0500 To: Mark Duffy , "Bob Penfield" , From: Melinda Shore Subject: Re: [midcom] Current status In-Reply-To: <3.0.5.32.20011102113046.007bee20@email.quarrytech.com> References: <017501c163b7$0b325ee0$2300000a@acmepacket.com> <5.1.0.14.0.20011031174517.00a5b0c0@mira-sjc5-4.cisco.com> <5.1.0.14.0.20011102102741.00a5dec0@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 11:30 AM 11/2/01 -0500, Mark Duffy wrote: >R82 makes the ruleset extensible. I think your point is that this allows >extension to specify interfaces/realms/in/out/etc. Of course that does not >help the agent with knowing what middleboxes are there and which to talk to. Exactly. The whole topology thing is fundamentally out-of- scope. It came up because of what were probably unnecessarily detailed discussions about precisely what information is known by which element, etc. That's not to say that those discussions were unimportant or irrelevant - they weren't, and whether the topology discussions are reflected in the deliverables for this iteration of the working group or not they'll bear on the deliverables for the rechartered working group. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Nov 2 15:13: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 ESMTP id PAA17029 for ; Fri, 2 Nov 2001 15:13:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA28824 for midcom-archive@odin.ietf.org; Fri, 2 Nov 2001 15:13: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 PAA28765; Fri, 2 Nov 2001 15:09: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 PAA28737 for ; Fri, 2 Nov 2001 15:09:10 -0500 (EST) Received: from hotmail.com (f110.pav1.hotmail.com [64.4.31.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16919 for ; Fri, 2 Nov 2001 15:09:08 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 2 Nov 2001 12:08:41 -0800 Received: from 207.5.1.168 by pv1fd.pav1.hotmail.msn.com with HTTP; Fri, 02 Nov 2001 20:08:40 GMT X-Originating-IP: [207.5.1.168] From: "James Ho" To: jdrosen@dynamicsoft.com, christopher.a.martin@wcom.com, bpenfield@acmepacket.com, bscott@ridgewaysystems.com, midcom@ietf.org Subject: RE: [midcom] pre-midcom candidates Date: Fri, 02 Nov 2001 12:08:40 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Nov 2001 20:08:41.0240 (UTC) FILETIME=[2AA28980:01C163DA] Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Two points. First, other then performance/latency issues (which I'd like to learn more about), I can't understand what is different about protocols targeted by midcom vs. protocols that have been and are securely supported by IPsec for firewall traversal. The whole pt of having standards such as Ipsec is that ITs confidence in allowing such protocols to be securely used is enhanced due to their standard status. I'm not sure defining new standards and/or proliferation of new protocols (especially for the focused purpose of firewall traversal of a specific set of media protocols) is going to enhance IT confidence or making security policy-setting easier. Finally, regarding performance, as I said earlier, the IP storage folks have standardized on IPsec as a mandatory component for authentication and integrity checking for iSCSI, FCIP, and iFCP protocols. These protocols have very stringent *round-trip* latency requirements, so it would behoove this group to carefully look at if the performance requirements of H.323/SIP are significantly different so as to justify standardizing on a new protocol. james >From: Jonathan Rosenberg >To: "'christopher.a.martin@wcom.com'" , >"'James Ho'" , bpenfield@acmepacket.com, >bscott@ridgewaysystems.com, midcom@ietf.org >Subject: RE: [midcom] pre-midcom candidates >Date: Fri, 2 Nov 2001 02:35:21 -0500 > > > > > > > -----Original Message----- > > From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] > > Sent: Thursday, November 01, 2001 1:46 PM > > To: 'James Ho'; bpenfield@acmepacket.com; bscott@ridgewaysystems.com; > > midcom@ietf.org > > Subject: RE: [midcom] pre-midcom candidates > > > > > > This would work well for an isolated network (intranet or > > extranet) but when > > it is desired to allow anyone (Internet) access it would be > > infeasible to > > provide security associations to the world > >Well, one need not do it to the world. Presumably, the VoIP provider would >offer this service to its customers. Then, it only need worry about >offering >ip addresses to the customers it has actively online. > > > > Also, IPSec doesnt provide security policy enforcement, as a firewall > > typically would on non-IPSec encapsulated packets, merely > > privacy. When you > > tunnel IPSec through a firewall from endpoints, unless the security > > associations are setup to be granular, the firewall cannot act on the > > packets inside the tunnel. > >No, they can't. Thats why it works. But thats also the problem shared by >all >the vpn and tunneling solutions; they ultimately work since they help >bypass >enterprise firewall policies that might exist. > >Stun doesn't do tunneling; if the firewall disallows outbound UDP then you >can't send outbound UDP. It therefore insures that enterprise firewall >policy continues to be obeyed. > > > Also not all firewalls allow IPSec (IP 50 and 51) the ability to pass > > through them. > >Pick your favorite vpn. Others get through and work. My favorite remains >RFC3093, which will traverse almost all firewalls and nats. > >-Jonathan R. > >--- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Nov 2 15:56:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17887 for ; Fri, 2 Nov 2001 15:56:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA29586 for midcom-archive@odin.ietf.org; Fri, 2 Nov 2001 15:56: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 PAA29392; Fri, 2 Nov 2001 15:43: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 PAA29363 for ; Fri, 2 Nov 2001 15:43:00 -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 ESMTP id PAA17572 for ; Fri, 2 Nov 2001 15:42:53 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fA2KgVX21737; Fri, 2 Nov 2001 12:42:31 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABV35023; Fri, 2 Nov 2001 12:35:53 -0800 (PST) Message-Id: <5.1.0.14.0.20011102151726.00a67990@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 02 Nov 2001 15:38:25 -0500 To: "James Ho" , midcom@ietf.org From: Melinda Shore Subject: RE: [midcom] pre-midcom candidates In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:08 PM 11/2/01 -0800, James Ho wrote: >The whole pt of having standards >such as Ipsec is that ITs confidence in allowing such protocols >to be securely used is enhanced due to their standard status. I'm not >sure defining new standards and/or proliferation of new >protocols (especially for the focused purpose of firewall traversal >of a specific set of media protocols) is going to enhance IT confidence >or making security policy-setting easier. If we must have this discussion (and I'd really rather we didn't - the working group was chartered some time ago under considerable scrutiny and we've nearly finished our work), we should start with the understanding that nobody is saying "never tunnel" and that we're not trying to supplant mechanisms that work. Midcom is a response to well-understood situations in which tunneling will *not* work or will work badly. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Nov 2 18:53:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22008 for ; Fri, 2 Nov 2001 18:53:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04753 for midcom-archive@odin.ietf.org; Fri, 2 Nov 2001 18:53:34 -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 SAA04734; Fri, 2 Nov 2001 18:51:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04706 for ; Fri, 2 Nov 2001 18:51:13 -0500 (EST) Received: from hotmail.com (f73.pav1.hotmail.com [64.4.31.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21997 for ; Fri, 2 Nov 2001 18:51:10 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 2 Nov 2001 15:50:43 -0800 Received: from 207.5.1.168 by pv1fd.pav1.hotmail.msn.com with HTTP; Fri, 02 Nov 2001 23:50:43 GMT X-Originating-IP: [207.5.1.168] From: "James Ho" To: mshore@cisco.com, midcom@ietf.org Subject: RE: [midcom] pre-midcom candidates Date: Fri, 02 Nov 2001 15:50:43 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Nov 2001 23:50:43.0478 (UTC) FILETIME=[2F4EBB60:01C163F9] Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org My earlier e-mail was only regarding the pre-midcom drafts (i.e. the requirements for the new midcom framework are clear while I'm not clear on the need to come up with a new protocol standard vs. use of an existing protocol standard for the pre-midcom work). Sorry if I'm bringing up issues that may have been hashedout before. Saqib >From: Melinda Shore >To: "James Ho" , midcom@ietf.org >Subject: RE: [midcom] pre-midcom candidates >Date: Fri, 02 Nov 2001 15:38:25 -0500 > >At 12:08 PM 11/2/01 -0800, James Ho wrote: > >The whole pt of having standards > >such as Ipsec is that ITs confidence in allowing such protocols > >to be securely used is enhanced due to their standard status. I'm not > >sure defining new standards and/or proliferation of new > >protocols (especially for the focused purpose of firewall traversal > >of a specific set of media protocols) is going to enhance IT confidence > >or making security policy-setting easier. > >If we must have this discussion (and I'd really rather we >didn't - the working group was chartered some time ago under >considerable scrutiny and we've nearly finished our work), we >should start with the understanding that nobody is saying "never >tunnel" and that we're not trying to supplant mechanisms that >work. Midcom is a response to well-understood situations in which >tunneling will *not* work or will work badly. > >Melinda > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Nov 2 19:03:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22121 for ; Fri, 2 Nov 2001 19:03:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA05206 for midcom-archive@odin.ietf.org; Fri, 2 Nov 2001 19:03: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 TAA05163; Fri, 2 Nov 2001 19:01: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 TAA05131 for ; Fri, 2 Nov 2001 19:01:23 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22093 for ; Fri, 2 Nov 2001 19:01:20 -0500 (EST) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.11.3/8.10.1) with ESMTP id fA303Xf48286; Sat, 3 Nov 2001 01:03:33 +0100 (CET) Received: from [192.168.102.22] ([192.168.102.22]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA20785; Sat, 3 Nov 2001 01:01:23 +0100 Date: Sat, 03 Nov 2001 01:02:46 +0100 From: Juergen Quittek To: midcom@ietf.org cc: stiemerling@ccrle.nec.de Message-ID: <4021986412.1004749366@[192.168.102.22]> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [midcom] very simple midcom-type protocol Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit We have submitted an Internet draft on the Simple NAT and Firewall Control (SNFC) protocol. Until it is available at the I-D repository, you can find it at http://www.ibr.cs.tu-bs.de/~quittek/draft-stiemerling-nat-fw-config-00.txt We will implement the SNFC protocol for the SOCKS firewall software. Our intention is to contribute to the current discussion on midcom requirements by emphasizing the principle of KISS. We are aware of the fact that SNFC does not meet all requirements currently under discussion. However, we believe that also a simple approach like ours can be very useful in many situations where middlebox control is desired. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Nov 5 02:31: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 ESMTP id CAA08831 for ; Mon, 5 Nov 2001 02:31:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA26879 for midcom-archive@odin.ietf.org; Mon, 5 Nov 2001 02:31: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 CAA26468; Mon, 5 Nov 2001 02:17: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 CAA26439 for ; Mon, 5 Nov 2001 02:17:20 -0500 (EST) Received: from web13802.mail.yahoo.com (web13802.mail.yahoo.com [216.136.175.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA08731 for ; Mon, 5 Nov 2001 02:17:18 -0500 (EST) Message-ID: <20011105071721.34555.qmail@web13802.mail.yahoo.com> Received: from [65.12.33.187] by web13802.mail.yahoo.com via HTTP; Sun, 04 Nov 2001 23:17:21 PST Date: Sun, 4 Nov 2001 23:17:21 -0800 (PST) From: Pyda Srisuresh Subject: Re: [midcom] Rev4 of MIDCOM Architecture & framework document To: Mark Duffy , midcom@ietf.org In-Reply-To: <3.0.5.32.20011102002146.008f6a90@email.quarrytech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --- Mark Duffy wrote: > Thank you Suresh, here are my comments. > These are just suggestions on the document, not I think on the fundamental > concepts. -- Mark. > OK. > > Section 2.15 -- definition of "Ruleset". I recommend we remove the second > paragraph: > Ruleset specifies the dynamic resources (i.e., Filter Specs, > Action Specs, Ruleset type, Timeout values etc.) that maybe > communicated through the MIDCOM protocol. > I don't think it adds much to the definition, and it introduces another new > undefined term ("resources"). There was some discussion of removing this > on the list 4 Oct. > The above sentence is meant to provide the context in which the term is applicable. SO, I will simply replace the above sentence as follows to avoid adding new terms. Rulesets are communicated through the Midcom protocol. > Section 6.0 -- policy server. In the third paragraph it states > The policy server acts in an advisory capacity to a middlebox to > authorize or terminate authorization for an agent to gain > connectivity to the middlebox. The primary objective of a policy > I think "gain connectivity to the middlebox" is a fairly imprecise wording. > Section 2.9 (policy server definition) has more/better description than > this section 6.0. Perhaps some of that can be moved here and replace some > of 6.0. Hope the following rewording will work for you. The policy server acts in an advisory capacity to a middlebox to authorize or terminate authorization for an agent attempting connectivity to the middlebox. > BTW my understanding, and I can read this into the section 2.9 > description but it is not unambiguously stated there, that the policy > server may govern which agents may establish midcom sessions with the > middlebox *and also* restrict what Rulesets a given agent may manipulate. > No? Perhaps we can clarify that. Mark -Please refer paragraph 2 of section 6.2. The docoument cannot be an exhaustive list of all the items people want to include in a policy server. The paragraph lists items that may be included, but not limited to these. > > Section 6.2 -- registration. The first paragraph explains that > registration is different than establishing a session. The phrase > "transport session" is used several times in this paragraph. I suggest > that the first two uses should be replaced with the recently defined term > "Midcom session". > OK. > Section 6.2. The third paragraph seems confusing. Also, it discusses > either the agent or the middlebox initiating the midcom session. My > understanding from the requirements discussion etc. is that we have come > around to only the agent initiating the session. I suggest modifying the > paragraph as follows: > The MIDCOM agent profile may be pre-configured on the middlebox while > provisioning the middlebox function. Thereafter, the agent may choose > to initiate a Midcom session prior to any data traffic. Alternatively, > it may choose to initiate a Midcom session only upon noticing the > application specific traffic. > You are right about the client-server conclusion. Only an agent is assumed initiate the session. So, the first 2 sentences make sense. But, the last sentence is perhaps meaningless in the context of client-server communication. How does a MIDCOM agent notice application specific traffic, without the middlebox informing it? A middlebox will not know to notify an agent it is not in session with. So, I will remove the last sentence. > Section 6.2. The 4th paragraph discusses "Coupling MIDCOM agents with the > middlebox ruleset". I'm not sure what that coupling refers to. Can we > clarify this? > The coupling (or preconfiguring) of Midcom agents with Filter Spec was described when a middlebox is permitted to initiate a session with an agent. When an Agent is preconfigured to be associated with a Filter Spec, the middlebox knows to invoke the agent for the first packet matching the Filter Spec. Now, I understand, a decision has been made by the WG that the MIDCOM protocol should be client-server type and not peer-to-peer. Sorry, I wasnt able to participate in the discussion at the time. So, I will go along with the WG decision. In the revised light of client-server type communication, I believe, the coupling of an Agent with Filter Spec is still relevant in that it refers to agent authorization policy (i.e., session tuples for which the agent is authorized to act as ALG) on the middlebox. I could reword the paragraph as follows. MIDCOM agent authorization policy may be preconfigured on a middlebox, by specifying the agent in conjunction with Filter Spec for a middlebox service. In the case of a firewall, for example, the ACL tuple may be altered to reflect the optional Agent presence. The revised ACL may look something like the following. (, , , , , , ) > Section 6.2. The seventh paragraph is confusing, and again contains the > concept of the middlebox initiating the midcom session. Since the main > purpose of this paragraph (I think) is to point out that the agent > information may be provisioned into a policy server rather than the > middlebox, and we've said that above, I suggest just omitting this paragraph. > This is about session termination (not initiation). SO, I dont believe there should be any confusion about middlebox initiating the MIDCOM session. Anyways, I am OK with dropping the paragraph. > Section 6.2, 8th paragraph. The first seven lines here are about midcom > session disconnection and have nothing to do with > registration/deregistration. Since they cover material already presented > in section 4, I suggest deleting them. > OK. > Section 11-security considerations. The first paragraph points out some > deleterious effects of middleboxes on security protocols. The second > paragraph seems to state that midcom can fix all this because the middlebox > will no longer need to inspect or modify data. The text should acknowledge > that the midcom model does not help with the problem of NAT breaking IPsec > since in this case the middlebox still modifies data that matters. > OK. I will add the following sentence at the end of second paragraph. Note, however, the MIDCOM framework does not help with the problem of NAT breaking IPsec since in this case the middlebox still modifies IP and transport headers. regards, suresh ===== __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Nov 5 10:15:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22421 for ; Mon, 5 Nov 2001 10:15:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA12919 for midcom-archive@odin.ietf.org; Mon, 5 Nov 2001 10:15:37 -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 KAA12417; Mon, 5 Nov 2001 10:01: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 KAA12389 for ; Mon, 5 Nov 2001 10:01:17 -0500 (EST) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21866 for ; Mon, 5 Nov 2001 10:01:15 -0500 (EST) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA07210 for ; Mon, 5 Nov 2001 09:00:40 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 5 Nov 2001 08:52:58 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Nov 2001 08:58:57 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F2AC@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Bob Penfield'" , midcom Cc: "Sanjoy Sen" Subject: RE: [midcom] pre-midcom candidates Date: Mon, 5 Nov 2001 08:58:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1660A.6061C1D0" X-Orig: Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1660A.6061C1D0 Content-Type: text/plain; charset="windows-1252" > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Friday, November 02, 2001 9:14 AM > To: midcom > Subject: Re: [midcom] pre-midcom candidates > > > ... > > I do think we need to address the symmetric NAT problem soon. > > The Sen proposal seems too narrow in its focus on SIP and RTP. It also > includes a midcom-like component in the protocol between the > SIP element and > the RTP proxy. To standardize this approach we would need to > standardize the > RTP proxy control protocol and we would virtually have > midcom. The RTP proxy > is just a specialized NAT middlebox. As far as standardization, the only requirement in the Sen proposal is the option tag (indicating to the Proxy that the client is behind the NAT) for the signaling path. For the RTP Proxy control, a device control protocol such as Megaco or MGCP can be used as is, i.e. there's no standardization effort required. For traditional Firewall/NAT control (Midcom), Megaco needs to be extended as has been described in: http://search.ietf.org/internet-drafts/draft-sct-midcom-megaco-00.txt http://search.ietf.org/internet-drafts/draft-sct-midcom-megaco-pkg-00.txt The Sen proposal is as close to Midcom as it gets & is the simplest of the three proposals. The proposal primarily addresses the needs of different (albeit, overlapping) market segments than STUN. STUN is useful for residential and perhaps some small/medium Enterprise scenarios, where Cone type of NAT's predominate. The Media Proxy is the ideal candidate for medium/large Enterprise and Carrier service providers. Not only the predominant FW/NAT configuration for medium/large Enterprises mimick the symmetric NAT behavior, but the signaling/media Proxy combination provides some key advantages in terms of route-pinning and service management (e.g., billing, legal intercept) for service providers, carriers. Thanks, Sanjoy ================================ Interactive Multimedia Server Carrier VoIP Nortel Networks Ph: 972-685-8274, Fax: 972-685-3813 Mobile: 972-571-2062 ------_=_NextPart_001_01C1660A.6061C1D0 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable RE: [midcom] pre-midcom candidates

> -----Original Message-----
> From: Bob Penfield [mailto:bpenfield@acmepacket.com= ]
> Sent: Friday, November 02, 2001 9:14 AM
> To: midcom
> Subject: Re: [midcom] pre-midcom = candidates
>
>
>
...
>
> I do think we need to address the symmetric NAT = problem soon.
>
> The Sen proposal seems too narrow in its focus = on SIP and RTP. It also
> includes a midcom-like component in the = protocol between the
> SIP element and
> the RTP proxy. To standardize this approach we = would need to
> standardize the
> RTP proxy control protocol and we would = virtually have
> midcom. The RTP proxy
> is just a specialized NAT middlebox.

As far as standardization, the only requirement in = the Sen proposal is the option tag (indicating to the Proxy that the = client is behind the NAT) for the signaling path. For the RTP Proxy = control, a device control protocol such as Megaco or MGCP can be used = as is, i.e. there's no standardization effort required. For traditional = Firewall/NAT control (Midcom), Megaco needs to be extended as has been = described in:

http://search.ietf.org/internet-drafts/draft-sct-midco= m-megaco-00.txt
http://search.ietf.org/internet-drafts/draft-sct-midco= m-megaco-pkg-00.txt

The Sen proposal is as close to Midcom as it gets = & is the simplest of the three proposals. The proposal primarily = addresses the needs of different (albeit, overlapping) market segments = than STUN. STUN is useful for residential and perhaps some small/medium = Enterprise scenarios, where Cone type of NAT's predominate. The Media = Proxy is the ideal candidate for medium/large Enterprise and Carrier = service providers. Not only the predominant FW/NAT configuration for = medium/large Enterprises mimick the symmetric NAT behavior, but the = signaling/media Proxy combination provides some key advantages in terms = of route-pinning and service management (e.g., billing, legal = intercept) for service providers, carriers.

Thanks,
Sanjoy

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Interactive Multimedia Server
Carrier VoIP
Nortel Networks
Ph: 972-685-8274, Fax: 972-685-3813
Mobile: 972-571-2062

------_=_NextPart_001_01C1660A.6061C1D0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Nov 6 00:51:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17316 for ; Tue, 6 Nov 2001 00:51:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA05779 for midcom-archive@odin.ietf.org; Tue, 6 Nov 2001 00:51: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 AAA05668; Tue, 6 Nov 2001 00:42:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA05643 for ; Tue, 6 Nov 2001 00:42:04 -0500 (EST) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17230 for ; Tue, 6 Nov 2001 00:42:04 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA65eCVW007223; Tue, 6 Nov 2001 00:40:12 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Nov 2001 00:41:30 -0500 Message-ID: From: Jonathan Rosenberg To: "'James Ho'" , mshore@cisco.com, midcom@ietf.org Subject: RE: [midcom] pre-midcom candidates Date: Tue, 6 Nov 2001 00:41:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: James Ho [mailto:jamesho37@hotmail.com] > Sent: Friday, November 02, 2001 6:51 PM > To: mshore@cisco.com; midcom@ietf.org > Subject: RE: [midcom] pre-midcom candidates > > > My earlier e-mail was only regarding the pre-midcom drafts > (i.e. the requirements for the new midcom framework are clear while > I'm not clear on the need to come up with a new protocol standard > vs. use of an existing protocol standard for the pre-midcom work). > Sorry if I'm bringing up issues that may have been hashedout before. THis is indeed a good question, and its the point I have been trying to make. There are a variety of VPN solutions, and many of them allow applications to traverse nat. There are drawbacks of the VPN solutions - increased latency and increased data traffic to the provider. Any solution which retains these drawbacks is just going to define yet-another VPN approach, and its not clear what the value of that is. There IS immmediate value in a solution that does not suffer these problems, and therefore does something different from VPN will do. That is the point to the stun proposal. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Nov 6 15:39:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02592 for ; Tue, 6 Nov 2001 15:39:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17821 for midcom-archive@odin.ietf.org; Tue, 6 Nov 2001 15:39: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 PAA17681; Tue, 6 Nov 2001 15:32:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17652 for ; Tue, 6 Nov 2001 15:32:37 -0500 (EST) Received: from avgw.vxserver.com (mail.ridgeway-sys.com [194.128.67.178]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02408 for ; Tue, 6 Nov 2001 15:32:32 -0500 (EST) Received: from ridgeway.ridgeway-sys.com ([10.1.1.1]) by avgw.vxserver.com (NAVGW 2.5.1.2) with SMTP id M2001110620295217572 ; Tue, 06 Nov 2001 20:29:52 GMT Received: by ThisAddressDoesNotExist with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Nov 2001 20:31:58 -0000 Message-ID: <00533D13955AD411AF3800A0C9B42639E92244@ThisAddressDoesNotExist> From: Steve Davies To: Christian Huitema , Steve Davies, midcom Cc: Melinda Shore , Jonathan Rosenberg Subject: RE: [midcom] pre-midcom candidates - the Davies Critique Date: Tue, 6 Nov 2001 20:31:55 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16702.132E9520" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C16702.132E9520 Content-Type: text/plain; charset="ISO-8859-1" Christian, Are we talking at cross purposes? I understand that the STUN protocol itself will go through the firewall in the manner you describe here, but I couldn't find anything in your draft to say how STUN would help VoIP traverse a firewalls/NAT combination or Symmetric NAT once it has discovered that the terminal is behind such a configuration. Indeed, the Davies draft explains how VoIP can successfully traverse this deployment configuration using the technique you describe here - i.e 'let a response come in to a packet sent from an internal port' using a policy that is (at least we have found) acceptable to the local IT manager. Steve -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: 31 October 2001 22:26 To: Steve Davies; midcom Cc: Melinda Shore; Jonathan Rosenberg Subject: RE: [midcom] pre-midcom candidates - the Davies Critique Steve, Your point regarding "Stun and firewalls" is mistaken. The STUN requirement is that if there is a firewall, it let a response come in to a packet sent from an internal port. This is the default behavior of most "residential NAT/firewall", and it is also an optional behavior in many enterprise firewalls. Whether such a policy is deemed acceptable by the local IT manager is debatable -- there are pros and cons. -- Christian Huitema -----Original Message----- From: Steve Davies [mailto:sdavies@ridgewaysystems.com] Sent: Wednesday, October 31, 2001 12:57 PM To: 'midcom' Cc: 'Melinda Shore'; 'Jonathan Rosenberg' Subject: RE: [midcom] pre-midcom candidates - the Davies Critique (Apologies if you get this twice. The first attempt was too long for the mailing list so I've deleted the history.).... Naturally, I don't entirely agree with Jonathan's analysis. Here is mine: The Sen Proposal: ----------------- I don't see the Sen proposal as an adequate near-term/pre-midcom solution for two main reasons: (a) it requires changes to the protocol: ---------------------------------------- In order to make the Sen proposal work we are told that a new service tag must be incorporated in the SIP Register request and a new SIP Ping (keep-alive) method must be incorporated. Not only will this take time to implement in SIP but presumably we'll also need corresponding protocol changes for Megaco, MGCP, H.323, etc. Or is Midcom SIP-specific? (b) it requires behavioural changes to the client: -------------------------------------------------- It requires symmetric RTP and the continual transmission of RTP and RTCP packets to keep the NAT bindings open. While symmetric RTP may be a good thing, that doesn't imply all applications have constant bi-directional streams - think of 'broadcast' type applications. Also why should terminals be expected to turn off silence suppression? How are endpoints to know when and when not to make this behavioural change? Other weaknesses of the proposal include a requirement on terminals to signal to the SIP proxy when they are behind a NAT. It is not explained how they are supposed to know whether or not they are. Additionally, the use of random ports on the RTP Proxy makes it difficult to protect such a device with a regular filtering firewall. Such configurations would be required for an enterprise do-it-yourself solution(the enterprise is its own provider) and by service providers wanting to protect their networks and service from DoS attacks. Note that correction of all these shortcomings results in the same architecture and method outlined in the Davies proposal. The Rosenberg/STUN Proposal: ---------------------------- Whilst I acknowledge the STUN proposal provides a method to determine the type of NAT a terminal may be behind, I view the proposal as incomplete and potentially impractical candidate as a near-term/pre-midcom solution. a) Firewalls are everywhere: ---------------------------- Whenever a firewall is deployed in conjunction with a NAT, irrespective of the type of NAT, the net result is equivalent to what the STUN method describes as a Symmetric NAT. In the case of symmetric NATs, the Rosenberg proposal acknowledges that a media intermediary/relay (or RTP Proxy) is required. However, the STUN proposal doesn't inform us what the architecture and method are for making calls in this case, although Jonathan acknowledges in his email that there are three solutions - the Davies proposal, the Sen proposal and an unpublished STUN proposal. Firewalls are a fact of life in all enterprises connected to the internet. An ever-increasing number of users are installing firewalls in their homes as well. The majority of calls will require a media intermediary/RTP Proxy. In other words, VoIP providers will have to install media intermediaries from Day One of any service. Can you imagine the subscription scenario if they don't: Customer: 'Please may I subscribe to your service' Provider: 'Is your terminal behind a firewall?' Customer: 'Yes' Provider: 'Sorry our service won't work for you' or 'Yes, but please place your terminal outside the firewall' or 'Yes, but you can only call other people not behind a firewall or symmetric NAT'. This is not what the VoIP industry needs right now! b) Too early to optimise: ------------------------- The STUN proposal boils down to a port saving technique for VoIP providers. But in a nascent market its impractical to start with a port saving technique particularly when its unquantifiable how many ports a provider may save. What providers need is a solution that is deployable in all cases - that implies a media intermediary solution. Trying to combine a port saving technique in conjunction with a media intermediary solution will add complexity that will delay and stall the VoIP market. From a provider's perspective, this delay and additional testing could far outweigh any savings gained by requiring fewer media intermediary ports. c) Unproven: ------------ i) TIMEOUTS. When a user is behind a firewall or symmetric NAT, to avoid use of a media intermediary the terminal must invoke the STUN protocol on a call by call basis. The STUN protocol requires potentially significant timeouts to expire in order to determine whether media may go direct. What will this do to call setup times? ii) NETWORK BASED NATS. There may be cases where the terminal determines that the media may go direct, but in fact the media passes through network based NATs and the call will fail. This would typically happen at the provider boundary, because the provider uses some internal addressing scheme or when passing from IPv4 to IPv6 networks. The solution would be to place the STUN server on the remote side of those network based NATs, but this would have the consequence of tromboning the media via those network based NATs for 'provider-internal' calls, defeating the reason for STUN. Alternatively, multiple STUN servers would need to be deployed - one for each different NAT location, but that then poses the question of how a terminal would know which STUN server to use on a call-by-call basis. Davies proposal: ---------------- The Davies proposal is very midcom-like. The Proxy Extension Agent (PEA) is like a MIDDLEBOX and the Application Proxy (AP) is like a MIDCOM AGENT. The AP is responsible for getting publicly reachable transport addresses on the PEA for external calls and publishing those addresses in the protocol messages. The Davies proposal simplifies the security policy problem being grappled with by MIDCOM to a very simple static policy administered and controlled by the IT manager and implemented on existing firewalls. Just three static pinholes are required to be configured in the firewall. Furthermore, these pinholes are outbound pinholes(i.e. out from the enterprise). Jonathan writes that in the Davies draft there are issues to do with consistency with enterprise firewall policy, but this is unsubstantiated. When details of these issues are provided, we will be happy to discuss them. The Davies method is entirely consistent with enterprise firewall policy - it is similar to, but actually far more restrictive than the firewall policy that allows web browsing for example. The Davies proposal's policy has been vetted by service providers and is already in commercial deployments - we can only assume enterprises find it acceptable. As well as being midcom-like, the Davies method has many other significant advantages: * It provides a 100% solution. It will work anywhere no matter how many and what type and combination of firewalls and NATs there are. * No change is required to any of the protocols. It is not even necessary for endpoints to implement symmetric RTP. * The implementation can be made transparent to the endpoints or be implemented by them. * Enterprise or Service Provider deployments are possible. The PEA may be deployed within a service provider's network or within the DMZ of an enterprise's own service centre. * Passing through a media intermediary is seen as enhancing security and saving IP addresses. Hiding an enterprise IP address from the remote party (only the transport addresses of the PEA are published in messages) is seen as a benefit and enables the enterprise to use the same IP address used for other Internet traffic. * Service Providers see a benefit in handling the media through PEA for several reasons. It enables them to hide the transport addresses of their other service equipment. It provides them with a suitable point to implement wire-tapping (e.g.CALEA) - ITSPs in many countries are bound to provide such capabilities. It also provides them with a media QOS execution point and it provides suitable IPv4/IPv6 migration boundary points. Jonathan seeks to belittle the Davies proposal by likening it to RSIP. I'm not sure what the point is here. It is true that we have borrowed and learnt from many of the principles and techniques used within the Internet. That's why we have well known ports, outbound initiated connections, and TCP multiplexing, so it's not surprising the method is recognisable and architecturally looks similar to other protocols. What is unique, is the way in which this method combines the different Internet techniques together with the transport of real-time UDP streams without any tunneling overhead. In fact, the single disadvantage of the Davies proposal is that it requires media intermediaries, but no-one has devised a non-media intermediary solution that solves all of today's firewall and NAT deployments. In any case, media intermediaries are not of much concern to service providers because they will co-locate those intermediaries with their access equipment in their POPs. In due course, those intermediaries may even be implemented in the access routers or Midcom will obviate them. Pre-Midcom Recommendation: -------------------------- Jonathan writes that he wants to tackle the harder stuff, i.e. firewalls and symmetric NATs, later. The fact of the matter is that the Davies proposal has solved the harder stuff already. It is the Davies proposal that is the low-hanging fruit because it addresses 100% of deployments and it has working examples. Surely this is where a pre-midcom solution must start. A VoIP provider needs it from Day One because it is very likely some/many customers will have a firewall or symmetric NAT. If in time, providers are seeking more efficient deployments or are seeking to reduce costs, then the Davies solution is easily extended to incorporate a STUN-like method. But before embarking on this effort it would be wise to judge the market need and determine when MIDCOM will kick in. Steve Davies ------_=_NextPart_001_01C16702.132E9520 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] pre-midcom candidates - the Davies Critique

Christian,

Are we talking at cross purposes? I understand that = the STUN protocol itself will go through the firewall in the manner you = describe here, but I couldn't find anything in your draft to say how = STUN would help VoIP traverse a firewalls/NAT combination or Symmetric = NAT once it has discovered that the terminal is behind such a = configuration. Indeed, the Davies draft explains how VoIP can = successfully traverse this deployment configuration using the technique = you describe here - i.e 'let a response come in to a packet sent from = an internal port' using a policy that is (at least we have found) = acceptable to the local IT manager.

Steve

-----Original Message-----
From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
Sent: 31 October 2001 22:26
To: Steve Davies; midcom
Cc: Melinda Shore; Jonathan Rosenberg
Subject: RE: [midcom] pre-midcom candidates - the = Davies Critique

Steve,

Your point regarding "Stun and firewalls" = is mistaken. The STUN
requirement is that if there is a firewall, it let a = response come in to
a packet sent from an internal port. This is the = default behavior of
most "residential NAT/firewall", and it is = also an optional behavior in
many enterprise firewalls. Whether such a policy is = deemed acceptable by
the local IT manager is debatable -- there are pros = and cons.

-- Christian Huitema

-----Original Message-----
From: Steve Davies [mailto:sdavies@ridgewaysyste= ms.com]
Sent: Wednesday, October 31, 2001 12:57 PM
To: 'midcom'
Cc: 'Melinda Shore'; 'Jonathan Rosenberg'
Subject: RE: [midcom] pre-midcom candidates - the = Davies Critique

(Apologies if you get this twice. The first attempt = was too long for the
mailing list so I've deleted the history.).... =
Naturally, I don't entirely agree with Jonathan's = analysis. Here is
mine:
The Sen Proposal:
-----------------
I don't see the Sen proposal as an adequate = near-term/pre-midcom
solution for two main reasons:
(a) it requires changes to the protocol:
----------------------------------------
In order to make the Sen proposal work we are told = that a new service
tag must be incorporated in the SIP Register request = and a new SIP Ping
(keep-alive) method must be incorporated. Not only = will this take time
to implement in SIP but presumably we'll also need = corresponding
protocol changes for Megaco, MGCP, H.323, etc. Or is = Midcom
SIP-specific?
(b) it requires behavioural changes to the client: =
-------------------------------------------------- =
It requires symmetric RTP and the continual = transmission of RTP and RTCP
packets to keep the NAT bindings open. While = symmetric RTP may be a good
thing, that doesn't imply all applications have = constant bi-directional
streams - think of 'broadcast' type applications. = Also why should
terminals be expected to turn off silence = suppression? How are endpoints
to know when and when not to make this behavioural = change?
Other weaknesses of the proposal include a = requirement on terminals to
signal to the SIP proxy when they are behind a NAT. = It is not explained
how they are supposed to know whether or not they = are. Additionally, the
use of random ports on the RTP Proxy makes it = difficult to protect such
a device with a regular filtering firewall. Such = configurations would be
required for an enterprise do-it-yourself = solution(the enterprise is its
own provider) and by service providers wanting to = protect their networks
and service from DoS attacks.
Note that correction of all these shortcomings = results in the same
architecture and method outlined in the Davies = proposal.
The Rosenberg/STUN Proposal:
----------------------------
Whilst I acknowledge the STUN proposal provides a = method to determine
the type of NAT a terminal may be behind, I view the = proposal as
incomplete and potentially impractical candidate as = a
near-term/pre-midcom solution.
a) Firewalls are everywhere:
----------------------------
Whenever a firewall is deployed in conjunction with = a NAT, irrespective
of the type of NAT, the net result is equivalent to = what the STUN method
describes as a Symmetric NAT. In the case of = symmetric NATs, the
Rosenberg proposal acknowledges that a media = intermediary/relay (or RTP
Proxy) is required. However, the STUN proposal = doesn't inform us what
the architecture and method are for making calls in = this case, although
Jonathan acknowledges in his email that there are = three solutions - the
Davies proposal, the Sen proposal and an unpublished = STUN proposal.
Firewalls are a fact of life in all enterprises = connected to the
internet. An ever-increasing number of users are = installing firewalls in
their homes as well. The majority of calls will = require a media
intermediary/RTP Proxy. In other words, VoIP = providers will have to
install media intermediaries from Day One of any = service. Can you
imagine the subscription scenario if they don't: =
Customer: 'Please may I subscribe to your service' =
Provider: 'Is your terminal behind a firewall?' =
Customer: 'Yes'
Provider: 'Sorry our service won't work for you' or = 'Yes, but please
place your terminal outside the firewall' or 'Yes, = but you can only call
other people not behind a firewall or symmetric = NAT'.
This is not what the VoIP industry needs right now! =
b) Too early to optimise:
-------------------------
The STUN proposal boils down to a port saving = technique for VoIP
providers. But in a nascent market its impractical = to start with a port
saving technique particularly when its = unquantifiable how many ports a
provider may save. What providers need is a solution = that is deployable
in all cases - that implies a media intermediary = solution. Trying to
combine a port saving technique in conjunction with = a media intermediary
solution will add complexity that will delay and = stall the VoIP market.
From a provider's perspective, this delay and = additional testing could
far outweigh any savings gained by requiring fewer = media intermediary
ports.
c) Unproven:
------------
i) TIMEOUTS. When a user is behind a firewall or = symmetric NAT, to avoid
use of a media intermediary the terminal must invoke = the STUN protocol
on a call by call basis. The STUN protocol requires = potentially
significant timeouts to expire in order to determine = whether media may
go direct. What will this do to call setup = times?
ii) NETWORK BASED NATS. There may be cases where the = terminal determines
that the media may go direct, but in fact the media = passes through
network based NATs and the call will fail. This = would typically happen
at the provider boundary, because the provider uses = some internal
addressing scheme or when passing from IPv4 to IPv6 = networks. The
solution would be to place the STUN server on the = remote side of those
network based NATs, but this would have the = consequence of tromboning
the media via those network based NATs for = 'provider-internal' calls,
defeating the reason for STUN. Alternatively, = multiple STUN servers
would need to be deployed - one for each different = NAT location, but
that then poses the question of how a terminal would = know which STUN
server to use on a call-by-call basis.
Davies proposal:
----------------
The Davies proposal is very midcom-like. The Proxy = Extension Agent (PEA)
is like a MIDDLEBOX and the Application Proxy (AP) = is like a MIDCOM
AGENT. The AP is responsible for getting publicly = reachable transport
addresses on the PEA for external calls and = publishing those addresses
in the protocol messages.
The Davies proposal simplifies the security policy = problem being
grappled with by MIDCOM to a very simple static = policy administered and
controlled by the IT manager and implemented on = existing firewalls. Just
three static pinholes are required to be configured = in the firewall.
Furthermore, these pinholes are outbound = pinholes(i.e. out from the
enterprise).
Jonathan writes that in the Davies draft there are = issues to do with
consistency with enterprise firewall policy, but = this is
unsubstantiated. When details of these issues are = provided, we will be
happy to discuss them. The Davies method is entirely = consistent with
enterprise firewall policy - it is similar to, but = actually far more
restrictive than the firewall policy that allows web = browsing for
example. The Davies proposal's policy has been = vetted by service
providers and is already in commercial deployments - = we can only assume
enterprises find it acceptable.
As well as being midcom-like, the Davies method has = many other
significant advantages:
* It provides a 100% solution. It will work anywhere = no matter how many
and what type and combination of firewalls and NATs = there are.
* No change is required to any of the protocols. It = is not even
necessary for endpoints to implement symmetric RTP. =
* The implementation can be made transparent to the = endpoints or be
implemented by them.
* Enterprise or Service Provider deployments are = possible. The PEA may
be deployed within a service provider's network or = within the DMZ of an
enterprise's own service centre.
* Passing through a media intermediary is seen as = enhancing security and
saving IP addresses. Hiding an enterprise IP address = from the remote
party (only the transport addresses of the PEA are = published in
messages) is seen as a benefit and enables the = enterprise to use the
same IP address used for other Internet = traffic.
* Service Providers see a benefit in handling the = media through PEA for
several reasons. It enables them to hide the = transport addresses of
their other service equipment. It provides them with = a suitable point to
implement wire-tapping (e.g.CALEA) - ITSPs in many = countries are bound
to provide such capabilities. It also provides them = with a media QOS
execution point and it provides suitable IPv4/IPv6 = migration boundary
points.
Jonathan seeks to belittle the Davies proposal by = likening it to RSIP.
I'm not sure what the point is here. It is true that = we have borrowed
and learnt from many of the principles and = techniques used within the
Internet. That's why we have well known ports, = outbound initiated
connections, and TCP multiplexing, so it's not = surprising the method is
recognisable and architecturally looks similar to = other protocols. What
is unique, is the way in which this method combines = the different
Internet techniques together with the transport of = real-time UDP streams
without any tunneling overhead.
In fact, the single disadvantage of the Davies = proposal is that it
requires media intermediaries, but no-one has = devised a non-media
intermediary solution that solves all of today's = firewall and NAT
deployments. In any case, media intermediaries are = not of much concern
to service providers because they will co-locate = those intermediaries
with their access equipment in their POPs. In due = course, those
intermediaries may even be implemented in the access = routers or Midcom
will obviate them.
Pre-Midcom Recommendation:
--------------------------
Jonathan writes that he wants to tackle the harder = stuff, i.e. firewalls
and symmetric NATs, later. The fact of the matter is = that the Davies
proposal has solved the harder stuff already. It is = the Davies proposal
that is the low-hanging fruit because it addresses = 100% of deployments
and it has working examples. Surely this is where a = pre-midcom solution
must start. A VoIP provider needs it from Day One = because it is very
likely some/many customers will have a firewall or = symmetric NAT. If in
time, providers are seeking more efficient = deployments or are seeking to
reduce costs, then the Davies solution is easily = extended to incorporate
a STUN-like method. But before embarking on this = effort it would be wise
to judge the market need and determine when MIDCOM = will kick in.
Steve Davies

------_=_NextPart_001_01C16702.132E9520-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Nov 8 15:25:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06024 for ; Thu, 8 Nov 2001 15:25:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA15202 for midcom-archive@odin.ietf.org; Thu, 8 Nov 2001 15:25:12 -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 PAA15137; Thu, 8 Nov 2001 15:21:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15111 for ; Thu, 8 Nov 2001 15:21:42 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05898 for ; Thu, 8 Nov 2001 15:21:38 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fA8KInx02036 for ; Thu, 8 Nov 2001 12:18:53 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABW79369; Thu, 8 Nov 2001 12:20:28 -0800 (PST) Message-Id: <5.1.0.14.0.20011108151614.00a8ba20@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 08 Nov 2001 15:23:14 -0500 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Requirements draft Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Unfortunately the original editors were not available to revise the requirements draft based on Scott's list so I've gone ahead and produced a new version myself. I expect that the internet-drafts queue is quite long right now and it may be a day or more before the draft is posted, so in the interim a copy is available at http://www.employees.org/~shore/draft-ietf-midcom-requirements-03.txt I have retained all of the agreed-upon requirements as well as the document structure, while trying to conform to the model provided by several requirements documents that have survived IESG review and been published as RFCs. I've added explanatory text as needed - please cast a particularly critical eye on that. The structure may need some tweaking, as well, and there's at least one requirement that duplicates another (2.3.1 and 2.3.2). Please have at it. I'm hoping that this will be the second-to-last draft - that is to say, the draft resulting from your comments on this will be the one to go to last call. Many thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Nov 8 16:17:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08110 for ; Thu, 8 Nov 2001 16:17:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA17197 for midcom-archive@odin.ietf.org; Thu, 8 Nov 2001 16:17:12 -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 QAA17087; Thu, 8 Nov 2001 16:14:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17058 for ; Thu, 8 Nov 2001 16:14:02 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07997 for ; Thu, 8 Nov 2001 16:14:00 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fA8LBJx02182 for ; Thu, 8 Nov 2001 13:11:20 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABW81400; Thu, 8 Nov 2001 13:12:56 -0800 (PST) Message-Id: <5.1.0.14.0.20011108161306.00a97390@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 08 Nov 2001 16:15:50 -0500 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Agenda for Salt Lake City Sender: 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 deadline for the Salt Lake City meeting agenda is drawing nigh, and I need to get it submitted. Right now the two topics I think we need to cover are 1) pre-midcom and 2) rechartering. Please let me know post-haste if there's something else you feel requires meeting time. We will not be discussing the framework or requirements documents. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Nov 9 07:14:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07603 for ; Fri, 9 Nov 2001 07:14:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA14253 for midcom-archive@odin.ietf.org; Fri, 9 Nov 2001 07:14: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 HAA13988; Fri, 9 Nov 2001 07:11: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 HAA13961 for ; Fri, 9 Nov 2001 07:11:34 -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 HAA07510; Fri, 9 Nov 2001 07:11:32 -0500 (EST) Message-Id: <200111091211.HAA07510@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 09 Nov 2001 07:11:32 -0500 Subject: [midcom] I-D ACTION:draft-ietf-midcom-requirements-03.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 Communications (midcom) Protocol Requirements Author(s) : R. Swale, P. Mart, P. Sijben, S. Brim, M. Shore Filename : draft-ietf-midcom-requirements-03.txt Pages : 10 Date : 08-Nov-01 This document specifies the requirements that the Middlebox Commu- nication (midcom) protocol must satisfy in order to meet the needs of applications wishing to influence middlebox function. These requirements were developed with a specific focus on network address translation and firewall middleboxes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-requirements-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-requirements-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-requirements-03.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: <20011108152156.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-requirements-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-requirements-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011108152156.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Nov 12 09:31:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02401 for ; Mon, 12 Nov 2001 09:31:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA04814 for midcom-archive@odin.ietf.org; Mon, 12 Nov 2001 09:31:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04448; Mon, 12 Nov 2001 09:29:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04417 for ; Mon, 12 Nov 2001 09:29:32 -0500 (EST) Received: from avgw.vxserver.com (mail.ridgeway-sys.com [194.128.67.178]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02224 for ; Mon, 12 Nov 2001 09:29:28 -0500 (EST) Received: from ridgeway.ridgeway-sys.com ([10.1.1.1]) by avgw.vxserver.com (NAVGW 2.5.1.14) with SMTP id M2001111214270700265 ; Mon, 12 Nov 2001 14:27:07 GMT Received: by ThisAddressDoesNotExist with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Nov 2001 14:28:56 -0000 Message-ID: <00533D13955AD411AF3800A0C9B42639E922F5@ThisAddressDoesNotExist> From: Steve Davies To: "'Bob Penfield'" , "'midcom'" Subject: RE: [midcom] pre-midcom candidates Date: Mon, 12 Nov 2001 14:28:51 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16B86.599289D0" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C16B86.599289D0 Content-Type: text/plain; charset="ISO-8859-1" Bob, In my opinion there is an underlying confusion in this debate. I believe * 'the discovery of the type of firewall/NAT combination a terminal is behind' is different from * 'the traversal of VoIP through any firewall/NAT combination' And because they are different, they don't necessarily need the same protocol. The reason we have lots of protocols is because they provide different functions. Trying to extend a protocol to handle substantially different tasks usually results in a cumbersome protocol that takes forever to produce. By definition pre-midcom needs to avoid this. The STUN protocol does the discovery piece very well. The Davies proposal does no discovery - it assumes apriori it's behind a Symmetric NAT (which includes a FW/NAT combination or just a FW.) The Davies proposal does the VoIP traversal very well. The STUN proposal does no traversal. Having discovered it is behind a Cone-type NAT, it requires terminal behavioural change to get the media flowing direct. As has already been noted, STUN does not help with Symmetric NAT or a firewall/NAT combination. It has also been noted that the extension of STUN to cope with Symmetric NAT would result in a method that would be very like the Davies proposal. Therefore for 100% deployment coverage, a pre-midcom solution would need either: 1. Davies proposal - don't care about Cone NAT for the time being or 2. Davies + STUN - some media may go direct I propose starting with 1. because it is less work than 2. and it has not been quantified whether it is worthwhile to adopt STUN for the percentage of calls it would affect in a pre-midcom timeframe. Other comments in-line below: Steve -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: 02 November 2001 15:14 To: midcom Subject: Re: [midcom] pre-midcom candidates Hi all, I just want to throw my hat into the ring as a supporter of the STUN proposal. It is very simple and will be relatively easy to implement directly in endpoints. It requires no state in the server side. It adheres to the security policy of the firewall/NAT owner. [SD] How can you say STUN adheres to the security policy of the firewall/NAT owner? It has already been noted that STUN offers no VoIP traversal solution through a firewall/NAT combination, so today it wouldn't be deployed in this case. Or are you saying the STUN protocol itself (minus traversal) adheres to the security policy? The Davies proposal also adheres very well to the security policy. Actually the mechanism the Davies proposal uses for traversal is very similar to the mechanism used to get the STUN protocol itself through the firewall. With STUN as a basic tool, more complex solutions can be developed. It could even be used to implement much of the Davies proposal. [SD] See my main point above. The discovery of the firewall/NAT combination is a different task to the actual traversal. If you are saying that STUN can be used to know when to use the Davies method then I agree, but that doesn't imply it's an extension of STUN, just that they could co-exist. The reason we have lots of protocols is because they all do different jobs. Extending one protocol to do lots of different jobs usually leads to going down a rat-hole. I do think we need to address the symmetric NAT problem soon. [SD] The Davies proposal has! The Sen proposal seems too narrow in its focus on SIP and RTP. It also includes a midcom-like component in the protocol between the SIP element and the RTP proxy. To standardize this approach we would need to standardize the RTP proxy control protocol and we would virtually have midcom. The RTP proxy is just a specialized NAT middlebox. There are number of things I find troubling about the Davies proposal: - The tunneling of the signaling through the firewall verges on subverting the security policy of the firewall owner. As others have stated, existing VPN methods can do this today. I also think that outbound TCP connections for signaling can work in most cases. [SD] The Davies proposal has ALL connections as outgoing connections. The firewall owner can choose to block the Davies protocol, if that is their policy. However we expect that they will choose to use a pre-midcom solution that fits their security policies, so there is no subversion. - The protocol that would be required to implement this solution seems to be too complex. I counted 12 methods. It seems to be as complex, if not more so, than midcom will need to be. How long will it take to devise and standardize it? Based on the claims of the draft, Ridgeway has devised this protocol, but have they published the details? Given the complexity, it will be more difficult and costly to develop endpoints that support it. Given that, intermediate devices will be needed until all the endpoints support it, which again increases the cost of deploying VOIP and other applications. [SD] Ridgeway will publish the details if it is the chosen pre-midcom candidate. The Davies proposal is more complex than STUN because it's solving a more complex problem than STUN, but that does not imply it's more complex than it needs to be. We can also infer that the Davies proposal is less complex than Midcom because it doesn't need to do any of the pin-holing that is required in Midcom. Cost of implementation generally decreases inline with competition. Standardization will enable that competition. I think STUN is the best alternative for an easy, quick, and cost effective solution for NAT/FW that will allow for wider deployment of VOIP and other applications. It provides an interim solution until midcom is completed and also is useful in the long term for scenarios where midcom is not appropriate. [SD] How can you make this claim when STUN doesn't solve the NAT/FW problem? cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C16B86.599289D0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] pre-midcom candidates

Bob,

In my opinion there is an underlying confusion in = this debate. I believe

* 'the discovery of the type of firewall/NAT = combination a terminal is behind'

is different from

* 'the traversal of VoIP through any firewall/NAT = combination'

And because they are different, they don't = necessarily need the same protocol. The reason we have lots of = protocols is because they provide different functions. Trying to extend = a protocol to handle substantially different tasks usually results in a = cumbersome protocol that takes forever to produce. By definition = pre-midcom needs to avoid this.

The STUN protocol does the discovery piece very well. = The Davies proposal does no discovery - it assumes apriori it's behind = a Symmetric NAT (which includes a FW/NAT combination or just a = FW.)

The Davies proposal does the VoIP traversal very = well. The STUN proposal does no traversal. Having discovered it is = behind a Cone-type NAT, it requires terminal behavioural change to get = the media flowing direct. As has already been noted, STUN does not help = with Symmetric NAT or a firewall/NAT combination. It has also been = noted that the extension of STUN to cope with Symmetric NAT would = result in a method that would be very like the Davies = proposal.

Therefore for 100% deployment coverage, a pre-midcom = solution would need either:

1. Davies proposal - don't care about Cone NAT for = the time being
or
2. Davies + STUN - some media may go direct

I propose starting with 1. because it is less work = than 2. and it has not been quantified whether it is worthwhile to = adopt STUN for the percentage of calls it would affect in a pre-midcom = timeframe.

Other comments in-line below:

Steve

-----Original Message-----
From: Bob Penfield [mailto:bpenfield@acmepacket.com= ]
Sent: 02 November 2001 15:14
To: midcom
Subject: Re: [midcom] pre-midcom candidates

Hi all,

I just want to throw my hat into the ring as a = supporter of the STUN
proposal.

It is very simple and will be relatively easy to = implement directly in
endpoints. It requires no state in the server side. = It adheres to the
security policy of the firewall/NAT owner.
[SD] How can you say STUN adheres to the security = policy of the firewall/NAT owner? It has already been noted that STUN = offers no VoIP traversal solution through a firewall/NAT combination, = so today it wouldn't be deployed in this case. Or are you saying the = STUN protocol itself (minus traversal) adheres to the security policy? = The Davies proposal also adheres very well to the security policy. = Actually the mechanism the Davies proposal uses for traversal is very = similar to the mechanism used to get the STUN protocol itself through = the firewall.

With STUN as a basic tool, more complex solutions can = be developed. It could
even be used to implement much of the Davies = proposal.
[SD] See my main point above. The discovery of the = firewall/NAT combination is a different task to the actual traversal. = If you are saying that STUN can be used to know when to use the Davies = method then I agree, but that doesn't imply it's an extension of STUN, = just that they could co-exist. The reason we have lots of protocols is = because they all do different jobs. Extending one protocol to do lots = of different jobs usually leads to going down a rat-hole.

I do think we need to address the symmetric NAT = problem soon.
[SD] The Davies proposal has!

The Sen proposal seems too narrow in its focus on SIP = and RTP. It also
includes a midcom-like component in the protocol = between the SIP element and
the RTP proxy. To standardize this approach we would = need to standardize the
RTP proxy control protocol and we would virtually = have midcom. The RTP proxy
is just a specialized NAT middlebox.

There are number of things I find troubling about the = Davies proposal:

- The tunneling of the signaling through the firewall = verges on subverting
the security policy of the firewall owner. As others = have stated, existing
VPN methods can do this today. I also think that = outbound TCP connections
for signaling can work in most cases.
[SD] The Davies proposal has ALL connections as = outgoing connections. The firewall owner can choose to block the Davies = protocol, if that is their policy. However we expect that they will = choose to use a pre-midcom solution that fits their security policies, = so there is no subversion.

- The protocol that would be required to implement = this solution seems to be
too complex. I counted 12 methods. It seems to be as = complex, if not more
so, than midcom will need to be. How long will it = take to devise and
standardize it? Based on the claims of the draft, = Ridgeway has devised this
protocol, but have they published the details? Given = the complexity, it will
be more difficult and costly to develop endpoints = that support it. Given
that, intermediate devices will be needed until all = the endpoints support
it, which again increases the cost of deploying VOIP = and other applications.
[SD] Ridgeway will publish the details if it is the = chosen pre-midcom candidate. The Davies proposal is more complex than = STUN because it's solving a more complex problem than STUN, but that = does not imply it's more complex than it needs to be. We can also infer = that the Davies proposal is less complex than Midcom because it doesn't = need to do any of the pin-holing that is required in Midcom. Cost of = implementation generally decreases inline with competition. = Standardization will enable that competition.

I think STUN is the best alternative for an easy, = quick, and cost effective
solution for NAT/FW that will allow for wider = deployment of VOIP and other
applications. It provides an interim solution until = midcom is completed and
also is useful in the long term for scenarios where = midcom is not
appropriate.
[SD] How can you make this claim when STUN doesn't = solve the NAT/FW problem?

cheers,
(-:bob

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

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

------_=_NextPart_001_01C16B86.599289D0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Nov 12 11:03:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08602 for ; Mon, 12 Nov 2001 11:03:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07251 for midcom-archive@odin.ietf.org; Mon, 12 Nov 2001 11:03: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 LAA07205; Mon, 12 Nov 2001 11:02: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 LAA07173 for ; Mon, 12 Nov 2001 11:02:21 -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 ESMTP id LAA08501 for ; Mon, 12 Nov 2001 11:02:18 -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.11.3/8.9.1) with ESMTP id fACG1nr25936; Mon, 12 Nov 2001 08:01:49 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABX45114; Mon, 12 Nov 2001 08:01:19 -0800 (PST) Message-Id: <5.1.0.14.0.20011112105836.00a58b60@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 12 Nov 2001 11:04:16 -0500 To: Steve Davies , "'Bob Penfield'" , "'midcom'" From: Melinda Shore Subject: RE: [midcom] pre-midcom candidates In-Reply-To: <00533D13955AD411AF3800A0C9B42639E922F5@ThisAddressDoesNotE xist> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 02:28 PM 11/12/01 +0000, Steve Davies wrote: >[SD] How can you make this claim when STUN doesn't solve the NAT/FW problem? I'd like to remind everybody that pre-midcom != midcom. That is to say, the intent is to get a simple hack addressing the hard problem (NAT traversal) out quickly. The work that's going to address NAT and firewall traversal and attempt to be thorough about it is midcom itself. Please, let's not get carried away. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Nov 12 11:56: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 ESMTP id LAA11102 for ; Mon, 12 Nov 2001 11:56:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09053 for midcom-archive@odin.ietf.org; Mon, 12 Nov 2001 11:56:54 -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 LAA08847; Mon, 12 Nov 2001 11:50:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08816 for ; Mon, 12 Nov 2001 11:50:02 -0500 (EST) Received: from avgw.vxserver.com (mail.ridgeway-sys.com [194.128.67.178]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10843 for ; Mon, 12 Nov 2001 11:49:58 -0500 (EST) Received: from ridgeway.ridgeway-sys.com ([10.1.1.1]) by avgw.vxserver.com (NAVGW 2.5.1.14) with SMTP id M2001111216473130459 ; Mon, 12 Nov 2001 16:47:31 GMT Received: by ThisAddressDoesNotExist with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Nov 2001 16:49:19 -0000 Message-ID: <00533D13955AD411AF3800A0C9B42639E92306@ThisAddressDoesNotExist> From: Steve Davies To: "'Melinda Shore'" , "'midcom'" Subject: RE: [midcom] pre-midcom candidates Date: Mon, 12 Nov 2001 16:49:17 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16B99.F7DE64C0" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C16B99.F7DE64C0 Content-Type: text/plain; charset="ISO-8859-1" Melinda, Are you moving the goal-posts? I thought the new deliverable was to: 'develop or document a protocol or approach that allows clients to indirectly obtain address bindings from midcom-unaware middleboxes, through communications with server elements on the public side of the middlebox' In my book a midcom-unaware middlebox could be a firewall, a firewall/NAT combination, or just a NAT, so a pre-midcom solution must enable the traversal of all these midcom-unaware devices - not just NATs. Steve -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: 12 November 2001 16:04 To: Steve Davies; 'Bob Penfield'; 'midcom' Subject: RE: [midcom] pre-midcom candidates At 02:28 PM 11/12/01 +0000, Steve Davies wrote: >[SD] How can you make this claim when STUN doesn't solve the NAT/FW problem? I'd like to remind everybody that pre-midcom != midcom. That is to say, the intent is to get a simple hack addressing the hard problem (NAT traversal) out quickly. The work that's going to address NAT and firewall traversal and attempt to be thorough about it is midcom itself. Please, let's not get carried away. Melinda ------_=_NextPart_001_01C16B99.F7DE64C0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] pre-midcom candidates

Melinda,

Are you moving the goal-posts? I thought the new = deliverable was to:

'develop or document a protocol or approach that = allows
clients to indirectly obtain address bindings from = midcom-unaware
middleboxes, through communications with server = elements on the public
side of the middlebox'

In my book a midcom-unaware middlebox could be a = firewall, a firewall/NAT combination, or just a NAT, so a pre-midcom = solution must enable the traversal of all these midcom-unaware devices = - not just NATs.

Steve

-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: 12 November 2001 16:04
To: Steve Davies; 'Bob Penfield'; 'midcom'
Subject: RE: [midcom] pre-midcom candidates

At 02:28 PM 11/12/01 +0000, Steve Davies = wrote:
>[SD] How can you make this claim when STUN = doesn't solve the NAT/FW problem?

I'd like to remind everybody that pre-midcom !=3D = midcom. That
is to say, the intent is to get a simple hack = addressing the hard
problem (NAT traversal) out quickly. The work = that's going to
address NAT and firewall traversal and attempt to be = thorough
about it is midcom itself. Please, let's not = get carried away.

Melinda

------_=_NextPart_001_01C16B99.F7DE64C0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Nov 12 12:03:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11311 for ; Mon, 12 Nov 2001 12:03:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10360 for midcom-archive@odin.ietf.org; Mon, 12 Nov 2001 12:03: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 MAA10213; Mon, 12 Nov 2001 12:02:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10185 for ; Mon, 12 Nov 2001 12:02:04 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11270 for ; Mon, 12 Nov 2001 12:02:00 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fACGxIx06366; Mon, 12 Nov 2001 08:59:19 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABX46615; Mon, 12 Nov 2001 09:01:02 -0800 (PST) Message-Id: <5.1.0.14.0.20011112115843.00a62400@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 12 Nov 2001 12:03:58 -0500 To: Steve Davies , "'midcom'" From: Melinda Shore Subject: RE: [midcom] pre-midcom candidates In-Reply-To: <00533D13955AD411AF3800A0C9B42639E92306@ThisAddressDoesNotE xist> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 04:49 PM 11/12/01 +0000, Steve Davies wrote: >Are you moving the goal-posts? Not at all. The goal was and remains to do something quickly that does NOT supplant midcom. If we spend months and months haggling over this we will have failed. If we develop something that does more-or-less what midcom will do but is even more ugly than midcom we will have failed. Etc. Remember, it's "pre-midcom," not "instead-of-midcom." Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Nov 12 12:28: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 ESMTP id MAA12074 for ; Mon, 12 Nov 2001 12:28:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11675 for midcom-archive@odin.ietf.org; Mon, 12 Nov 2001 12:28:54 -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 MAA11596; Mon, 12 Nov 2001 12:27: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 MAA11565 for ; Mon, 12 Nov 2001 12:27:24 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12041 for ; Mon, 12 Nov 2001 12:27:20 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.04) id A67B76C900CC; Mon, 12 Nov 2001 12:27:23 -0500 Message-ID: <007001c16b9e$de0a3420$2300000a@acmepacket.com> From: "Bob Penfield" To: "Steve Davies" , "'Melinda Shore'" , "'midcom'" References: <00533D13955AD411AF3800A0C9B42639E92306@ThisAddressDoesNotExist> Subject: Re: [midcom] pre-midcom candidates Date: Mon, 12 Nov 2001 12:24:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > > 'develop or document a protocol or approach that allows > clients to indirectly obtain address bindings from midcom-unaware > middleboxes, through communications with server elements on the public > side of the middlebox' > Regardless of whether its a NAT or a firewall, "indirectly obtain address bindings .... through communications with server elements" sounds a lot more like 'the discovery of the type of firewall/NAT combination a terminal is behind' than 'the traversal of VoIP through any firewall/NAT combination'. Address binding discovery is what the STUN proposal addresses rather than a complete the VOIP solution. We're not even required to deal with the symetric-NAT problem. This is something that we need to submit to the IESG ASAP (in 2001). In fact, according to the midcom web-page (which says Oct 01), we're already late. BTW, shouldn't we get the above verbage on the pre-midcom deliverable on the IETF midcom web-page? It just has a milestone right now. (-:bob _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Nov 12 12:34:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12290 for ; Mon, 12 Nov 2001 12:34:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12464 for midcom-archive@odin.ietf.org; Mon, 12 Nov 2001 12:34:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12398; Mon, 12 Nov 2001 12: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 MAA12370 for ; Mon, 12 Nov 2001 12:33:39 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12263 for ; Mon, 12 Nov 2001 12:33:37 -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.11.3/8.9.1) with ESMTP id fACHXAn13809; Mon, 12 Nov 2001 09:33:11 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABX47767; Mon, 12 Nov 2001 09:32:40 -0800 (PST) Message-Id: <5.1.0.14.0.20011112123426.00a65770@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 12 Nov 2001 12:35:36 -0500 To: "Bob Penfield" , "'midcom'" From: Melinda Shore Subject: Re: [midcom] pre-midcom candidates In-Reply-To: <007001c16b9e$de0a3420$2300000a@acmepacket.com> References: <00533D13955AD411AF3800A0C9B42639E92306@ThisAddressDoesNotExist> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:24 PM 11/12/01 -0500, Bob Penfield wrote: >BTW, shouldn't we get the above verbage on the pre-midcom deliverable on the >IETF midcom web-page? It just has a milestone right now. There are still discussions going on in the IESG/IAB. I'll let you know as soon as there's some sort of resolution. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Nov 12 12:37:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12534 for ; Mon, 12 Nov 2001 12:37:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12844 for midcom-archive@odin.ietf.org; Mon, 12 Nov 2001 12:37:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12642; Mon, 12 Nov 2001 12:36: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 MAA12607 for ; Mon, 12 Nov 2001 12:35:56 -0500 (EST) Received: from avgw.vxserver.com (mail.ridgeway-sys.com [194.128.67.178]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12410 for ; Mon, 12 Nov 2001 12:35:54 -0500 (EST) Received: from ridgeway.ridgeway-sys.com ([10.1.1.1]) by avgw.vxserver.com (NAVGW 2.5.1.14) with SMTP id M2001111217332327368 ; Mon, 12 Nov 2001 17:33:24 GMT Received: by ThisAddressDoesNotExist with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Nov 2001 17:35:11 -0000 Message-ID: <00533D13955AD411AF3800A0C9B42639E9230D@ThisAddressDoesNotExist> From: Steve Davies To: "'Melinda Shore'" Cc: "'midcom'" Subject: RE: [midcom] pre-midcom candidates Date: Mon, 12 Nov 2001 17:35:06 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16BA0.5E668140" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C16BA0.5E668140 Content-Type: text/plain; charset="ISO-8859-1" I think I agreed. I assumed and still assume that a pre-midcom solution is a solution that enables FW/NAT traversal through legacy equipment. Once Midcom is finished, gradually FW/NATs would be replaced by Midcom-aware devices obviating the pre-midcom solution. Users would migrate from pre-midcom to Midcom because Midcom would be better. In the case of the Davies proposal, a media intermediary is required. Midcom is better because it dispenses with that need. The need for a pre-midcom solution is clear. The market is stalled waiting for Midcom. But to liberate the industry the pre-midcom solution should address, I believe, all midcom-unaware middleboxes whether they be just a FW, a FW/NAT combination or just a NAT. Is this correct? Steve -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: 12 November 2001 17:04 To: Steve Davies; 'midcom' Subject: RE: [midcom] pre-midcom candidates At 04:49 PM 11/12/01 +0000, Steve Davies wrote: >Are you moving the goal-posts? Not at all. The goal was and remains to do something quickly that does NOT supplant midcom. If we spend months and months haggling over this we will have failed. If we develop something that does more-or-less what midcom will do but is even more ugly than midcom we will have failed. Etc. Remember, it's "pre-midcom," not "instead-of-midcom." Melinda ------_=_NextPart_001_01C16BA0.5E668140 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] pre-midcom candidates

I think I agreed. I assumed and still assume that a = pre-midcom solution is a solution that enables FW/NAT traversal through = legacy equipment. Once Midcom is finished, gradually FW/NATs would be = replaced by Midcom-aware devices obviating the pre-midcom solution. = Users would migrate from pre-midcom to Midcom because Midcom would be = better. In the case of the Davies proposal, a media intermediary is = required. Midcom is better because it dispenses with that need. The = need for a pre-midcom solution is clear. The market is stalled waiting = for Midcom. But to liberate the industry the pre-midcom solution should = address, I believe, all midcom-unaware middleboxes whether they be just = a FW, a FW/NAT combination or just a NAT.

Is this correct?

Steve

-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: 12 November 2001 17:04
To: Steve Davies; 'midcom'
Subject: RE: [midcom] pre-midcom candidates

At 04:49 PM 11/12/01 +0000, Steve Davies = wrote:
>Are you moving the goal-posts?

Not at all. The goal was and remains to do = something quickly
that does NOT supplant midcom. If we spend = months and
months haggling over this we will have failed. = If we develop
something that does more-or-less what midcom will do = but is
even more ugly than midcom we will have = failed. Etc. Remember,
it's "pre-midcom," not = "instead-of-midcom."

Melinda

------_=_NextPart_001_01C16BA0.5E668140-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Nov 12 13:19:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14002 for ; Mon, 12 Nov 2001 13:19:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA14249 for midcom-archive@odin.ietf.org; Mon, 12 Nov 2001 13:19:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14171; Mon, 12 Nov 2001 13:17:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14141 for ; Mon, 12 Nov 2001 13:17:38 -0500 (EST) Received: from rhenium (rhenium.btinternet.com [194.73.73.93]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13936 for ; Mon, 12 Nov 2001 13:17:36 -0500 (EST) Received: from [213.122.130.231] (helo=tkw) by rhenium with smtp (Exim 3.22 #6) id 163LeI-0002hU-00; Mon, 12 Nov 2001 18:17:35 +0000 Message-ID: <005001c16ba6$3ee012e0$0200000a@tkw> From: "Pete Cordell" To: "Steve Davies" , "'Bob Penfield'" , "'midcom'" , "Melinda Shore" References: <5.1.0.14.0.20011112105836.00a58b60@localhost> Subject: Re: [midcom] pre-midcom candidates Date: Mon, 12 Nov 2001 18:16:26 -0000 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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I'm just wondering if there is any point to developing a solution that does not address the firewall. Most enterprises will have firewalls, and the percentage of residential firewalls can only go up. (As has been said elsewhere, the presence of a firewall effectively makes the NAT symmetric. The consensus so far seems to be that such NATs need additional steps beyond discovering what type they are to get the protocols through.) Also, many dial-up residential cases do not have to contend with NAT at all. My feeling is that if we don't address the firewall, we will have spent time developing something that helps out only a very few cases, and really doesn't move us any closer to where we want to be. The result would be to delay real midcom with no gain. Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Melinda Shore To: Steve Davies ; 'Bob Penfield' ; 'midcom' Sent: 12 November 2001 16:04 Subject: RE: [midcom] pre-midcom candidates > At 02:28 PM 11/12/01 +0000, Steve Davies wrote: > >[SD] How can you make this claim when STUN doesn't solve the NAT/FW problem? > > I'd like to remind everybody that pre-midcom != midcom. That > is to say, the intent is to get a simple hack addressing the hard > problem (NAT traversal) out quickly. The work that's going to > address NAT and firewall traversal and attempt to be thorough > about it is midcom itself. Please, let's not get carried away. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Nov 12 17:24:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21191 for ; Mon, 12 Nov 2001 17:24:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19730 for midcom-archive@odin.ietf.org; Mon, 12 Nov 2001 17:24: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 RAA19638; Mon, 12 Nov 2001 17:22: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 RAA19582 for ; Mon, 12 Nov 2001 17:22:36 -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 ESMTP id RAA21047 for ; Mon, 12 Nov 2001 17:22:33 -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.11.3/8.9.1) with ESMTP id fACMM6r08094 for ; Mon, 12 Nov 2001 14:22:06 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABX59565; Mon, 12 Nov 2001 14:21:36 -0800 (PST) Message-Id: <5.1.0.14.0.20011112171347.00a721f0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 12 Nov 2001 17:24:18 -0500 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Proposed agenda for Salt Lake City Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Notes: 1) We will not be discussing the framework or requirements documents, but you should be familiar with their contents in order to be prepared for the rechartering discussion 2) You'll note that my network-friendlier draft is on the agenda. I've tried to be careful about not abusing my position in order to promote fringe technology, but this document has gotten very positive feedback and in discussion with the ADs there was agreement that it would be discussed in the context of rechartering. Either Scott Bradner or Allison will be chairing that section of the meeting. 3) The pre-midcom discussion is subject to whatever constraints come out of current offline discussions. Melinda Middlebox Communication WG (midcom) Monday, December 10 at 1930-2200 ================================== CHAIR: Melinda Shore AGENDA: Agenda bashing, scribe Status Rechartering Pre-midcom Documents: http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-05.txt http://www.ietf.org/internet-drafts/draft-ietf-midcom-requirements-03.txt http://search.ietf.org/internet-drafts/draft-shore-friendly-midcom-00.txt http://search.ietf.org/internet-drafts/draft-sen-midcom-fw-nat-00.txt http://search.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-00.txt http://search.ietf.org/internet-drafts/draft-davies-fw-nat-traversal-01.txt _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Nov 13 07:13:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20735 for ; Tue, 13 Nov 2001 07:13:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA12309 for midcom-archive@odin.ietf.org; Tue, 13 Nov 2001 07:14:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11909; Tue, 13 Nov 2001 07:09:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11881 for ; Tue, 13 Nov 2001 07:09:16 -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 HAA20392; Tue, 13 Nov 2001 07:09:14 -0500 (EST) Message-Id: <200111131209.HAA20392@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 13 Nov 2001 07:09:14 -0500 Subject: [midcom] I-D ACTION:draft-ietf-midcom-framework-05.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : Middlebox Communication Architecture and framework Author(s) : P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan Filename : draft-ietf-midcom-framework-05.txt Pages : 36 Date : 12-Nov-01 There are a variety of intermediate devices in the Internet today that require application intelligence for their operation. Datagrams pertaining to real-time streaming applications such as SIP and H.323 and peer-to-peer applications such as Napster and NetMeeting cannot be identified by merely examining packet headers. . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-framework-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-framework-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011112111907.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-framework-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-framework-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011112111907.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Nov 13 10:10:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28769 for ; Tue, 13 Nov 2001 10:10:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA15870 for midcom-archive@odin.ietf.org; Tue, 13 Nov 2001 10:10:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15723; Tue, 13 Nov 2001 10:03:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15694 for ; Tue, 13 Nov 2001 10:03:15 -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 ESMTP id KAA28110 for ; Tue, 13 Nov 2001 10:03:13 -0500 (EST) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fADF2rn06615 for ; Tue, 13 Nov 2001 07:02:53 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABX78225; Tue, 13 Nov 2001 07:02:17 -0800 (PST) Message-Id: <5.1.0.14.0.20011113100329.00a6b350@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 13 Nov 2001 10:05:14 -0500 To: midcom@ietf.org From: Melinda Shore Subject: Fwd: [midcom] I-D ACTION:draft-ietf-midcom-framework-05.txt 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 Now that the new revision of the framework draft is available I am starting working group last call. Please post comments to the mailing list. Last call will close on 27 November at 5pm PST. Melinda >To: IETF-Announce: ; >Cc: midcom@ietf.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Date: Tue, 13 Nov 2001 07:09:14 -0500 >Subject: [midcom] I-D ACTION:draft-ietf-midcom-framework-05.txt >Sender: midcom-admin@ietf.org >X-Mailman-Version: 1.0 >List-Id: >X-BeenThere: midcom@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Middlebox Communication Working Group of the IETF. > > Title : Middlebox Communication Architecture and framework > Author(s) : P. Srisuresh, J. Kuthan, J. Rosenberg, > A. Molitor, A. Rayhan > Filename : draft-ietf-midcom-framework-05.txt > Pages : 36 > Date : 12-Nov-01 > >There are a variety of intermediate devices in the Internet today >that require application intelligence for their operation. >Datagrams pertaining to real-time streaming applications such >as SIP and H.323 and peer-to-peer applications such as Napster >and NetMeeting cannot be identified by merely examining packet >headers. . > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-05.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-midcom-framework-05.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-midcom-framework-05.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20011112111907.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-midcom-framework-05.txt > > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Nov 13 13:00:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08929 for ; Tue, 13 Nov 2001 13:00:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20865 for midcom-archive@odin.ietf.org; Tue, 13 Nov 2001 13:00:21 -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 MAA20641; Tue, 13 Nov 2001 12:57:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20609 for ; Tue, 13 Nov 2001 12:57:03 -0500 (EST) Received: from avgw.vxserver.com (mail.ridgeway-sys.com [194.128.67.178]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08722 for ; Tue, 13 Nov 2001 12:57:01 -0500 (EST) Received: from ridgeway.ridgeway-sys.com ([10.1.1.1]) by avgw.vxserver.com (NAVGW 2.5.1.14) with SMTP id M2001111317534422303 ; Tue, 13 Nov 2001 17:53:44 GMT Received: by ThisAddressDoesNotExist with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 17:56:20 -0000 Message-ID: <00533D13955AD411AF3800A0C9B42639172435@ThisAddressDoesNotExist> From: Steve Davies To: "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] Proposed agenda for Salt Lake City Date: Tue, 13 Nov 2001 17:56:13 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16C6C.7C315480" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C16C6C.7C315480 Content-Type: text/plain; charset="ISO-8859-1" Melinda, re: 3 below. What offline discussions are going on and who has representation in them? Steve www.ridgewaysystems.com -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: 12 November 2001 22:24 To: midcom@ietf.org Subject: [midcom] Proposed agenda for Salt Lake City Notes: 1) We will not be discussing the framework or requirements documents, but you should be familiar with their contents in order to be prepared for the rechartering discussion 2) You'll note that my network-friendlier draft is on the agenda. I've tried to be careful about not abusing my position in order to promote fringe technology, but this document has gotten very positive feedback and in discussion with the ADs there was agreement that it would be discussed in the context of rechartering. Either Scott Bradner or Allison will be chairing that section of the meeting. 3) The pre-midcom discussion is subject to whatever constraints come out of current offline discussions. Melinda Middlebox Communication WG (midcom) Monday, December 10 at 1930-2200 ================================== CHAIR: Melinda Shore AGENDA: Agenda bashing, scribe Status Rechartering Pre-midcom Documents: http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-05.txt http://www.ietf.org/internet-drafts/draft-ietf-midcom-requirements-03.txt http://search.ietf.org/internet-drafts/draft-shore-friendly-midcom-00.txt http://search.ietf.org/internet-drafts/draft-sen-midcom-fw-nat-00.txt http://search.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-00.txt http://search.ietf.org/internet-drafts/draft-davies-fw-nat-traversal-01.txt _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C16C6C.7C315480 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Proposed agenda for Salt Lake City

Melinda,

re: 3 below.

What offline discussions are going on and who has = representation in them?

Steve
www.ridgewaysystems.com

-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: 12 November 2001 22:24
To: midcom@ietf.org
Subject: [midcom] Proposed agenda for Salt Lake = City

Notes:
1) We will not be discussing the framework or = requirements documents,
but you should be familiar with their contents in = order to be prepared
for the rechartering discussion
2) You'll note that my network-friendlier draft is = on the agenda. I've
tried to be careful about not abusing my position in = order to promote
fringe technology, but this document has gotten very = positive feedback
and in discussion with the ADs there was agreement = that it would be
discussed in the context of rechartering. = Either Scott Bradner or
Allison will be chairing that section of the = meeting.
3) The pre-midcom discussion is subject to whatever = constraints come
out of current offline discussions.

Melinda

Middlebox Communication WG (midcom)

Monday, December 10 at 1930-2200
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

CHAIR: Melinda Shore <mshore@cisco.com>

AGENDA:

Agenda bashing, scribe
Status
Rechartering
Pre-midcom

Documents:
http://www.ietf.org/internet-drafts/draft-ietf-midcom-= framework-05.txt
http://www.ietf.org/internet-drafts/draft-ietf-midcom-= requirements-03.txt
http://search.ietf.org/internet-drafts/draft-shore-fri= endly-midcom-00.txt
http://search.ietf.org/internet-drafts/draft-sen-midco= m-fw-nat-00.txt
http://search.ietf.org/internet-drafts/draft-rosenberg= -midcom-stun-00.txt
http://search.ietf.org/internet-drafts/draft-davies-fw= -nat-traversal-01.txt

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

------_=_NextPart_001_01C16C6C.7C315480-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Nov 13 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 ESMTP id NAA09930 for ; Tue, 13 Nov 2001 13:17:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21496 for midcom-archive@odin.ietf.org; Tue, 13 Nov 2001 13:17: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 NAA21401; Tue, 13 Nov 2001 13:15: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 NAA21371 for ; Tue, 13 Nov 2001 13:15:36 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09795 for ; Tue, 13 Nov 2001 13:15:33 -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.11.3/8.9.1) with ESMTP id fADIF6n06829; Tue, 13 Nov 2001 10:15:06 -0800 (PST) Received: from spandex.cisco.com (ssh-rtp1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABX84258; Tue, 13 Nov 2001 10:14:36 -0800 (PST) Message-Id: <5.1.0.14.0.20011113131542.00a7e040@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 13 Nov 2001 13:17:13 -0500 To: Steve Davies , midcom@ietf.org From: Melinda Shore Subject: RE: [midcom] Proposed agenda for Salt Lake City In-Reply-To: <00533D13955AD411AF3800A0C9B42639172435@ThisAddressDoesNotE xist> 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: