From midcom-admin@ietf.org Mon Jul 2 08:13:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06814 for ; Mon, 2 Jul 2001 08:13:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09238; Mon, 2 Jul 2001 08:05:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09211 for ; Mon, 2 Jul 2001 08:05:33 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06712 for ; Mon, 2 Jul 2001 08:04:49 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f62C4sw29423 for ; Mon, 2 Jul 2001 13:04:54 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Mon, 2 Jul 2001 13:04:20 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jul 2001 13:04:10 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C3044504E@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'Bob Penfield'" Cc: "Midcom IETF (E-mail)" Subject: RE: [midcom] Re: draft-ietf-midcom-requirements-01.txt Date: Mon, 2 Jul 2001 13:04:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C102EF.1964CBC0" Sender: 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_01C102EF.1964CBC0 Content-Type: text/plain; charset="iso-8859-1" Bob, I agree that setting dynamically certain flow's priorities might be required: -This could be done through the application's signaling and marked at the endpoint (IP telephony is one of these applications) -It could also be done at the Middle Box covering the endpoint, this is done through MIDCOM So we found an agreement on that. This will require that the Middle Box has the mapping of the Midcom Agent Service Class priorities to DSCP marking, this is required because there is no "uniform" PHBs between networks. Thanks Cedric -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: Friday, June 29, 2001 4:52 PM To: Aoun, Cedric [QPD:0000:EXCH] Subject: Re: [midcom] Re: draft-ietf-midcom-requirements-01.txt ----- Original Message ----- From: "Cedric Aoun" To: "'Bob Penfield'" Sent: Friday, June 29, 2001 9:57 AM Subject: RE: [midcom] Re: draft-ietf-midcom-requirements-01.txt > > > > John, > > We all agree that the Middle Box is a policy enforcement point, but > > there is no need to define a PHB on per call, the main purpose of Diffserv > > is to do traffic prioritization and assign a behavior for certain type of > > traffic classified > > by the flow priority (the DSCP in our case). > > These PHBs are on the MB either by manual config or > > by propping down policies from a Policy Decision Point. > > I don't see the need to discuss that in the context of MIDCOM. > > I disagree. The idea is that a midcom agent be able to "assign" one of these > established PHBs to a flow it is enabling thru the middlebox. I don't think > anybody wants to use MIDCOM to define PHBs. We just need to be able set the > priority for a flow that would otherwise get ordinary best-efforts > treatment. > > The application server can also request the application end point > to put the appropriate DSCP setting for the packet. This is already done in > most > IP telephony products. > But the point is valid for applications that have not developed this > capability, > this is required to ensure that the flows are assigned proper > classification. > ...Cedric > In a multi-domain scenario, QOS treatment needs to be applied within each domain. An application endpoint in a different network cannot do MPLS insertion or DSCP setting for PHBs defined in my network. These need to be applied as the packets enter my network. (-:bob ------_=_NextPart_001_01C102EF.1964CBC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Re: draft-ietf-midcom-requirements-01.txt

Bob,
I agree that setting dynamically certain flow's = priorities might be required:
-This could be done through the application's = signaling and marked at the endpoint (IP telephony is one of these = applications)

-It could also be done at the Middle Box covering the = endpoint, this is done through MIDCOM

So we found an agreement on that.
This will require that the Middle Box has the = mapping of the Midcom Agent Service Class priorities
to DSCP marking, this is required because there is = no "uniform" PHBs between networks.
Thanks

Cedric

-----Original Message-----
From: Bob Penfield [mailto:bpenfield@acmepacket.com= ]
Sent: Friday, June 29, 2001 4:52 PM
To: Aoun, Cedric [QPD:0000:EXCH]
Subject: Re: [midcom] Re: = draft-ietf-midcom-requirements-01.txt



----- Original Message -----
From: "Cedric Aoun" = <CEDRIC.AOUN@nortelnetworks.com>
To: "'Bob Penfield'" = <bpenfield@acmepacket.com>
Sent: Friday, June 29, 2001 9:57 AM
Subject: RE: [midcom] Re: = draft-ietf-midcom-requirements-01.txt


>
>
> > John,
> > We all agree that the Middle Box is a = policy enforcement point, but
> > there is no need to define a PHB on per = call, the main purpose of
Diffserv
> > is to do traffic prioritization and assign = a behavior for certain type
of
> > traffic classified
> > by the flow priority (the DSCP in our = case).
> > These PHBs are on the MB either by manual = config or
> > by propping down policies from a Policy = Decision Point.
> > I don't see the need to discuss that in = the context of MIDCOM.
>
> I disagree. The idea is that a midcom agent be = able to "assign" one of
these
> established PHBs to a flow it is enabling thru = the middlebox. I don't
think
> anybody wants to use MIDCOM to define PHBs. We = just need to be able set
the
> priority for a flow that would otherwise get = ordinary best-efforts
> treatment.
>
> <CA> The application server can also = request the application end point
> to put the appropriate DSCP setting for the = packet. This is already done
in
> most
> IP telephony products.
> But the point is valid for applications that = have not developed this
> capability,
> this is required to ensure that the flows are = assigned proper
> classification.
> ...Cedric
>
In a multi-domain scenario, QOS treatment needs to = be applied within each
domain. An application endpoint in a different = network cannot do MPLS
insertion or DSCP setting for PHBs defined in my = network. These need to be
applied as the packets enter my network.

(-:bob

------_=_NextPart_001_01C102EF.1964CBC0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 2 08:20:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06876 for ; Mon, 2 Jul 2001 08:20:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09558; Mon, 2 Jul 2001 08:14:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09523 for ; Mon, 2 Jul 2001 08:14:34 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06826 for ; Mon, 2 Jul 2001 08:13:51 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f62CE7h00448; Mon, 2 Jul 2001 05:14:07 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sj-dial-4-84.cisco.com [171.68.181.213]) by airborne.cisco.com (Mirapoint) with ESMTP id AFC01031; Mon, 2 Jul 2001 05:13:59 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 Q); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15165.55230.390000.302983@gargle.gargle.HOWL> Date: Sat, 30 Jun 2001 09:44:30 -0400 To: Pyda Srisuresh Cc: midcom@ietf.org Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 In-Reply-To: <20010625215719.47236.qmail@web13801.mail.yahoo.com> References: <15152.49874.182000.181304@gargle.gargle.HOWL> <20010625215719.47236.qmail@web13801.mail.yahoo.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit On 25 Jun 2001 at 14:57 -0700, Pyda Srisuresh apparently wrote: > --- Scott Brim wrote: > > On 19 Jun 2001 at 13:11 -0700, Pyda Srisuresh apparently wrote: > > > 1. Paragraph 1 of section 1 - Introduction > > > > > > "Application Level gateways (ALGs) are used in conjunction with NAT > > > to provide end-to-end transparency for many of the applications." > > > > > > I think, it should be OK to leave this unchanged. > > > > OK, we're talking about application-layer transparency. As long as you > > mean that the application data and the application behavior are > > unchanged, since that would fit the strict definition. I think I agree. > > > > ALG does not guarantee that application data is not changed, even though > its intention is to keep the application behaviour unchanged. > It may in fact change the data in control payloads. So, the term > "application level transparency" above doesnt meet the dictionary > definition. > > Would the following rewording work for you? > > Application Level gateways (ALGs) are used in conjunction with NAT > to examine and optionally modify application payload so the > end-to-end application behaviour remains unchanged for many > of the applications traversing NAT middleboxes. Yes, thanks. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 2 08:22:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06894 for ; Mon, 2 Jul 2001 08:22:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09658; Mon, 2 Jul 2001 08:18:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09625 for ; Mon, 2 Jul 2001 08:18:29 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06858 for ; Mon, 2 Jul 2001 08:17:45 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f62CHvw02184 for ; Mon, 2 Jul 2001 13:17:57 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Mon, 2 Jul 2001 13:17:39 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jul 2001 13:17:25 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C3044504F@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'John LaCour'" , "'Christian Huitema'" , "'midcom@ietf.org'" Subject: RE: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Date: Mon, 2 Jul 2001 13:17:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C102F0.EF00FAF0" Sender: 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_01C102F0.EF00FAF0 Content-Type: text/plain; charset="iso-8859-1" Part of the WG effort is to ensure extensibility of the MIDCOM protocol to interact with Middle Box's functions that are not only Packet filtering and NAT. QoS gating functions will be required too, especially on access links. Therefore we should not shut the door on having a descriptor for dynamic prioritization of certain flows (especially for applications that can't do this dynamic preordination), and bandwidth reservation requests descriptors(Peak packet rate, sustained rate, ...) Cedric ---------- I agree about charter creep, but lets not paint ourselves into a corner that excludes it for future consideration. > -- Christian Huitema -John _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C102F0.EF00FAF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Re: I-D = ACTION:draft-ietf-midcom-framework-02.txt

Part of the WG effort is to ensure extensibility of = the MIDCOM protocol
to interact with Middle Box's functions that are not = only Packet filtering and
NAT. QoS gating functions will be required too, = especially on access links.
Therefore we should not shut the door on having a = descriptor for dynamic prioritization
of certain flows (especially for applications that = can't do this dynamic preordination), and
bandwidth reservation requests descriptors(Peak = packet rate, sustained rate, ...)
Cedric


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

> -- Christian Huitema

-John

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

------_=_NextPart_001_01C102F0.EF00FAF0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 2 08:37:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07048 for ; Mon, 2 Jul 2001 08:37:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA10025; Mon, 2 Jul 2001 08:32:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA10000 for ; Mon, 2 Jul 2001 08:32:48 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06975 for ; Mon, 2 Jul 2001 08:32:04 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f62CWGh07709; Mon, 2 Jul 2001 05:32:16 -0700 (PDT) Received: from spandex (rtp-vpn-199.cisco.com [10.82.192.199]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AMH01055; Mon, 2 Jul 2001 05:31:54 -0700 (PDT) Message-ID: <01a001c102f3$1f7d5320$d45904d1@cisco.com> From: "Melinda Shore" To: "Cedric Aoun" , "'John LaCour'" , "'Christian Huitema'" , References: <9154CB41F208D5118DD200508BE39C3044504F@zjguc006.europe.nortel.com> Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Date: Mon, 2 Jul 2001 08:32:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > From: "Cedric Aoun" > To: "'John LaCour'" ; "'Christian Huitema'" ; > Sent: Monday, July 02, 2001 8:17 AM > Subject: RE: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt > Therefore we should not shut the door on having a descriptor for dynamic > prioritization of certain flows (especially for applications that can't > do this dynamic preordination), and bandwidth reservation requests > descriptors(Peak packet rate, sustained rate, ...) I think it would be helpful if people advocating doing something about QoS signaling would be specific about what they'd like to see in the documents. While we do need to keep extensibility and broader applicability in mind, QoS is definitely out of scope for the working group and what we can put in the documents is limited by that. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 2 10:51:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06723 for ; Mon, 2 Jul 2001 10:51:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14820; Mon, 2 Jul 2001 10:46:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14789 for ; Mon, 2 Jul 2001 10:46:47 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02406 for ; Mon, 2 Jul 2001 10:46:00 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA18362; Mon, 2 Jul 2001 15:46:09 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA27036; Mon, 2 Jul 2001 15:46:07 +0100 Message-ID: <3B40891C.B0AB78EC@hursley.ibm.com> Date: Mon, 02 Jul 2001 09:45:48 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Randy Turner CC: "'Bob Penfield '" , "'Mark Duffy '" , "'midcom@ietf.org '" Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt References: <91CDB24C5FCDD31198A2009027E79021011BDB6F@exchange.2wire.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 Randy Turner wrote: > > > DiffServ *can* be end-to-end if endpoints and intermediaries follow the > guidelines for the standard set of codepoints, as the relate to EF or AF > forwarding. But we cannot rely on it. It requires all ISPs on the path to have interlocking SLAs and that is not a safe assumption. Brian > > Randy > > -----Original Message----- > From: Bob Penfield > To: Brian E Carpenter; Mark Duffy > Cc: midcom@ietf.org > Sent: 6/29/01 2:42 PM > Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt > > ----- Original Message ----- > From: "Brian E Carpenter" > To: "Mark Duffy" > Cc: "Bob Penfield" ; > Sent: Friday, June 29, 2001 5:16 PM > Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt > > > Mark Duffy wrote: > > > > > > >Diffserv doesn't have per-flow classifiers, so there is nothing a > SIP > > > >proxy can say for a single new flow. The policy system has to > define a > > > >classifier for each *type* of traffic, not for individual flows. > This > is > > > >done globally per diffserv domain and is relatively static. > > > > > > > >The classifier will be given the appropriate classifier > specifications > > > >by the diffserv policy system. These are n-tuple specifications > just > > > >like any other. If you grok MIB they look like: > > > > > > > >DiffServSixTupleClfrEntry ::= SEQUENCE { > > > > diffServSixTupleClfrId INTEGER, > > > > diffServSixTupleClfrDstAddrType InetAddressType, > > > > diffServSixTupleClfrDstAddr InetAddress, > > > > diffServSixTupleClfrDstPrefixLength InetAddressPrefixLength, > > > > diffServSixTupleClfrSrcAddrType InetAddressType, > > > > diffServSixTupleClfrSrcAddr InetAddress, > > > > diffServSixTupleClfrSrcPrefixLength InetAddressPrefixLength, > > > > diffServSixTupleClfrDscp DscpOrAny, > > > > diffServSixTupleClfrProtocol Unsigned32, > > > > diffServSixTupleClfrDstL4PortMin InetPortNumber, > > > > diffServSixTupleClfrDstL4PortMax InetPortNumber, > > > > diffServSixTupleClfrSrcL4PortMin InetPortNumber, > > > > diffServSixTupleClfrSrcL4PortMax InetPortNumber, > > > > diffServSixTupleClfrStatus RowStatus > > > >} > > > > > > Yes, but since the flows of type 'SIP' come on dynamic ports, you > can't > > > readily match them using a classifier like that. > > > > There's nothing to prevent you defining a classifier that uses > > some other n-tuple that does identify media traffic. > > > > > However, a middlebox aka > > > diffserv-domain-edge-traffic-conditioning-box that is aware of which > flows > > > are SIP could apply a *static* policy that says mark SIP packets (or > > > perhaps, SIP packets to/from certain addresses) with a certain DSCP. > And > > > in the spirit of midcom, one would want the midcom agent to tell the > > > middlebox about this flow (perhaps not what DSCP to use, but that it > is > SIP). > > > > It would all be much simpler if the source of the media stream marked > its > > own packets; then neither the proxy nor the middlebox need to worry > about > it. > > That is in fact the simplest realisation of diffserv. > > But diffserv is not end-to-end, right? If the flow is traversing several > Autonomous Systems, won't each AS apply different QOS measures? The > combination of a SIP proxy and a middlebox can constitute an ALG which > is > often implemented as what SIP calls a back-to-back user agent which > terminates and re-generates the flow. In this case, the middlebox > becomes > the source of the media flow within the local AS. > > > > > All this goes to show that it's a complex topic, beyond what I thought > midcom > > was intended for. > > > > Brian > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 2 10:52:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06906 for ; Mon, 2 Jul 2001 10:52:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14739; Mon, 2 Jul 2001 10:45:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14715 for ; Mon, 2 Jul 2001 10:45:00 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01424 for ; Mon, 2 Jul 2001 10:44:16 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA13232; Mon, 2 Jul 2001 15:44:20 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA78254; Mon, 2 Jul 2001 15:44:19 +0100 Message-ID: <3B4088B2.481DDEEA@hursley.ibm.com> Date: Mon, 02 Jul 2001 09:44:03 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Cedric Aoun CC: "'Bob Penfield'" , "Midcom IETF (E-mail)" Subject: Re: [midcom] Re: draft-ietf-midcom-requirements-01.txt References: <9154CB41F208D5118DD200508BE39C3044504E@zjguc006.europe.nortel.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 > Cedric Aoun wrote: > > Bob, > I agree that setting dynamically certain flow's priorities might be required: > -This could be done through the application's signaling and marked at the endpoint (IP telephony is one of these applications) > > -It could also be done at the Middle Box covering the endpoint, this is done through MIDCOM > > So we found an agreement on that. > This will require that the Middle Box has the mapping of the Midcom Agent Service Class priorities > to DSCP marking, this is required because there is no "uniform" PHBs between networks. DSCPs are not priorities. I think the true statement is that it is entirely appropriate for a middlebox to *also* act as a diffserv node, getting its diffserv configuration from ... somewhere, not necessarily the midcom agent. I still object to QOS being shown as a fundamental part of the midcom model, although I agree that we should not close the door in the design. Brian > Thanks > > Cedric > > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Friday, June 29, 2001 4:52 PM > To: Aoun, Cedric [QPD:0000:EXCH] > Subject: Re: [midcom] Re: draft-ietf-midcom-requirements-01.txt > > ----- Original Message ----- > From: "Cedric Aoun" > To: "'Bob Penfield'" > Sent: Friday, June 29, 2001 9:57 AM > Subject: RE: [midcom] Re: draft-ietf-midcom-requirements-01.txt > > > > > > > > John, > > > We all agree that the Middle Box is a policy enforcement point, but > > > there is no need to define a PHB on per call, the main purpose of > Diffserv > > > is to do traffic prioritization and assign a behavior for certain type > of > > > traffic classified > > > by the flow priority (the DSCP in our case). > > > These PHBs are on the MB either by manual config or > > > by propping down policies from a Policy Decision Point. > > > I don't see the need to discuss that in the context of MIDCOM. > > > > I disagree. The idea is that a midcom agent be able to "assign" one of > these > > established PHBs to a flow it is enabling thru the middlebox. I don't > think > > anybody wants to use MIDCOM to define PHBs. We just need to be able set > the > > priority for a flow that would otherwise get ordinary best-efforts > > treatment. > > > > The application server can also request the application end point > > to put the appropriate DSCP setting for the packet. This is already done > in > > most > > IP telephony products. > > But the point is valid for applications that have not developed this > > capability, > > this is required to ensure that the flows are assigned proper > > classification. > > ...Cedric > > > In a multi-domain scenario, QOS treatment needs to be applied within each > domain. An application endpoint in a different network cannot do MPLS > insertion or DSCP setting for PHBs defined in my network. These need to be > applied as the packets enter my network. > > (-:bob _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 2 11:14:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24708 for ; Mon, 2 Jul 2001 11:14:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15453; Mon, 2 Jul 2001 11:04:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15422 for ; Mon, 2 Jul 2001 11:04:39 -0400 (EDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16174 for ; Mon, 2 Jul 2001 11:03:50 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA21279 for ; Mon, 2 Jul 2001 10:05:42 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 2 Jul 2001 10:03:09 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jul 2001 10:03:03 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43016BC001@crchy271.us.nortel.com> From: "Sanjoy Sen" To: "'Bob Penfield'" , Brian E Carpenter , midcom Subject: RE: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Date: Mon, 2 Jul 2001 10:02:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10308.1555A2C0" Sender: 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_01C10308.1555A2C0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Friday, June 29, 2001 6:37 AM > To: Brian E Carpenter; midcom > Subject: Re: [midcom] Re: I-D > ACTION:draft-ietf-midcom-framework-02.txt > > > Being able to set the DS code point is definitely something that > applications are going to want to do. For example, a SIP > proxy acting as a > midcom agent talking to a middlebox at the border between > networks will need > to instruct the middlebox to set the DSCP in the RTP packets > that will flow > thru the middlebox. The RTP packets will not flow thru the > SIP proxy/midcom > agent. The middlebox is the only place the application will be able to > affect QoS for the data flows. > Or, the SIP Proxy (MA) may be able to engage a PDP to set the DS filters in the Middlebox. Does this mean that we may also need to define, in future, an interface between the MA and the PDP? Sanjoy ------_=_NextPart_001_01C10308.1555A2C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Re: I-D = ACTION:draft-ietf-midcom-framework-02.txt

> -----Original Message-----
> From: Bob Penfield [mailto:bpenfield@acmepacket.com= ]
> Sent: Friday, June 29, 2001 6:37 AM
> To: Brian E Carpenter; midcom
> Subject: Re: [midcom] Re: I-D
> = ACTION:draft-ietf-midcom-framework-02.txt
>
>
> Being able to set the DS code point is = definitely something that
> applications are going to want to do. For = example, a SIP
> proxy acting as a
> midcom agent talking to a middlebox at the = border between
> networks will need
> to instruct the middlebox to set the DSCP in = the RTP packets
> that will flow
> thru the middlebox. The RTP packets will not = flow thru the
> SIP proxy/midcom
> agent. The middlebox is the only place the = application will be able to
> affect QoS for the data flows.
>

Or, the SIP Proxy (MA) may be able to engage a PDP to = set the DS filters in the Middlebox. Does this mean that we may also = need to define, in future, an interface between the MA and the = PDP?

Sanjoy







 

------_=_NextPart_001_01C10308.1555A2C0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 2 13:40:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00534 for ; Mon, 2 Jul 2001 13:40:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20728; Mon, 2 Jul 2001 13:29:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20696 for ; Mon, 2 Jul 2001 13:28:57 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22520 for ; Mon, 2 Jul 2001 13:28:12 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA23544; Mon, 2 Jul 2001 18:28:22 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA35236; Mon, 2 Jul 2001 18:28:19 +0100 Message-ID: <3B40AE2C.1FD6CAE8@hursley.ibm.com> Date: Mon, 02 Jul 2001 12:23:56 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Sanjoy Sen CC: "'Bob Penfield'" , midcom Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt References: <85AA7486A2C1D411BCA20000F8073E43016BC001@crchy271.us.nortel.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 > Sanjoy Sen wrote: > > > -----Original Message----- > > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > > Sent: Friday, June 29, 2001 6:37 AM > > To: Brian E Carpenter; midcom > > Subject: Re: [midcom] Re: I-D > > ACTION:draft-ietf-midcom-framework-02.txt > > > > > > Being able to set the DS code point is definitely something that > > applications are going to want to do. For example, a SIP > > proxy acting as a > > midcom agent talking to a middlebox at the border between > > networks will need > > to instruct the middlebox to set the DSCP in the RTP packets > > that will flow > > thru the middlebox. The RTP packets will not flow thru the > > SIP proxy/midcom > > agent. The middlebox is the only place the application will be able to > > affect QoS for the data flows. > > > > Or, the SIP Proxy (MA) may be able to engage a PDP to set the DS filters in the Middlebox. Does this mean that we may also > need to define, in future, an interface between the MA and the PDP? We won't be changing QOS policy on a per-call basis, so I don't see why that would be needed. Brian _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 2 17:35:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00125 for ; Mon, 2 Jul 2001 17:35:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29453; Mon, 2 Jul 2001 17:22:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29422 for ; Mon, 2 Jul 2001 17:22:44 -0400 (EDT) Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21871 for ; Mon, 2 Jul 2001 17:22:00 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id 6744F8133 for ; Mon, 2 Jul 2001 16:21:22 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id QAA23743 for ; Mon, 2 Jul 2001 16:21:22 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Mon, 2 Jul 2001 16:21:21 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt In-Reply-To: <3B40AE2C.1FD6CAE8@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Mon, 2 Jul 2001, Brian E Carpenter wrote: > We won't be changing QOS policy on a per-call basis, so I don't see > why that would be needed. I'm not entirely sure what this means, but I do have a comment. It is certainly desireable to be able to set things QoS and bandwidth parameters on a call by call (actually on a media-stream-by-media-stream) basis. Obviously things like video have different bandwidth requirements, and may have different QoS requirements than, say, an audio stream. It is not at all clear to me that it's useful to: - change QoS/bandwidth parameters on a given stream after it's set up. - support fine grained control (probably sufficient to allow a handful of "grades" of service with guidelines, and map a requested service grade into whatever works underneath. E.G an Agent could ask for 'DATA', 'PHONE', 'CD', or 'VIDEO' or something. Also, something the IP Telephony chaps will soon want to offer is 'premium' audio service as well as perhaps 'cheaper' audio service. Not that I have heard anyone talking about it, but it seems a no-brainer (and relatively simple) to build equipment capable of delivering phone/FM/CD quality audio. Then a service provider can turn the ability to deliver various audio grades into a differentiators and revenue streams. It is clearly desirable to allow something like a SIP Proxy server to actively provision network elements with QoS/bandwidth parameters. My personal opinion is that MIDCOM is the right place to do this -- but I am also happy to concur that MIDCOM should table that issue in favor of, say, getting something done now. Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 2 17:39:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03071 for ; Mon, 2 Jul 2001 17:39:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29928; Mon, 2 Jul 2001 17:32:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29899 for ; Mon, 2 Jul 2001 17:32:29 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28050 for ; Mon, 2 Jul 2001 17:31:45 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA24308 for ; Mon, 2 Jul 2001 14:30:28 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id OAA06628 for ; Mon, 2 Jul 2001 14:31:22 -0700 (PDT) Received: from xch-pssbh-03.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP; Mon, 2 Jul 2001 14:31:10 -0700 Received: by xch-pssbh-03.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id <3B4CVBZR>; Mon, 2 Jul 2001 14:31:10 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12E09@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'Andrew Molitor'" , midcom@ietf.org Subject: RE: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Date: Mon, 2 Jul 2001 14:31:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org >From: Andrew Molitor [mailto:amolitor@visi.com] >I'm not entirely sure what this means, but I do have a comment. >It is certainly desireable to be able to set things QoS and bandwidth >parameters on a call by call (actually on a media-stream-by-media-stream) >basis. Obviously things like video have different bandwidth requirements, >and may have different QoS requirements than, say, an audio stream. It is >not at all clear to me that it's useful to: When our peers wrote that QoS is outside of Midcom's scope, they weren't meaning that Midcom Agents -- or any other appropriate device -- can't do QoS. They were intending, rather, that there is NOTHING SPECIAL QoS-wise about Midcom -- that Midcom has no special QoS requirements nor any special "binding" to QoS that needs to be documented in our specs -- and that QoS issues are therefore out of our scope. When you make your implementation, therefore, you can do anything appropriate regarding QoS. However, you are doing this for standard QoS-related reasons, not because of the midcom protocol. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 2 17:58:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15004 for ; Mon, 2 Jul 2001 17:58:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00442; Mon, 2 Jul 2001 17:54:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00411 for ; Mon, 2 Jul 2001 17:54:41 -0400 (EDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12062 for ; Mon, 2 Jul 2001 17:53:56 -0400 (EDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 02 Jul 2001 14:47:04 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 2 Jul 2001 14:46:52 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 2 Jul 2001 14:47:03 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 2 Jul 2001 14:46:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Date: Mon, 2 Jul 2001 14:46:19 -0700 Message-ID: Thread-Topic: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt thread-index: AcEDPZ9oWgx4Nx8tR0Wdj4bSqOGZSQAAiGnQ From: "Christian Huitema" To: "Andrew Molitor" , X-OriginalArrivalTime: 02 Jul 2001 21:46:18.0135 (UTC) FILETIME=[6CCE8A70:01C10340] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA00412 Sender: 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 > -----Original Message----- > From: Andrew Molitor [mailto:amolitor@visi.com] > Sent: Monday, July 02, 2001 2:21 PM > To: midcom@ietf.org > Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt > > > > On Mon, 2 Jul 2001, Brian E Carpenter wrote: > > > We won't be changing QOS policy on a per-call basis, so I don't see > > why that would be needed. > > I'm not entirely sure what this means, but I do have a comment. > It is certainly desireable to be able to set things QoS and bandwidth > parameters on a call by call (actually on a media-stream-by-media-stream) > basis. That may or may not be desirable, but that is not in scope. There are other working groups that are dealing with the issue of QoS signaling; MIDCOM is not licensed to invent an alternative to Intserv or Diffserv. An obvious reason for QoS signaling being out of scope is that it affects many more boxes than just firewalls and NATs. Indeed, some could argue that anything in the network is a middle box, but that is pushing a bit. For better or worse, the group was chartered for dealing with firewalls and NATs, not to re-engineer routing. The group's membership reflects its initial focus; extending the scope at this late hour is a bad idea. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 2 18:04:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18859 for ; Mon, 2 Jul 2001 18:04:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00826; Mon, 2 Jul 2001 18:01:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00799 for ; Mon, 2 Jul 2001 18:01:05 -0400 (EDT) Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16080 for ; Mon, 2 Jul 2001 18:00:20 -0400 (EDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id VAA13836; Mon, 2 Jul 2001 21:58:23 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 02 Jul 2001 21:58:23 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jul 2001 14:58:21 -0700 Message-ID: From: "Maciocco, Christian" To: midcom@ietf.org Cc: "'ietf-openproxy@imc.org'" Date: Mon, 2 Jul 2001 14:58:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [midcom] Proxies / ALG in Midcom framework document Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org While the Midcom framework scope is defined to be NAT & Firewall in the Introduction chapter I think that describing Proxies and especially ALG later in the doc is confusing about this WG charter. There have been a lot of "proposed extension" lately, e.g. QoS support, OOP w/ packets diversion, etc. We should make sure to focus the document to transport level issues only. The concern I have if we describe ALG in this doc at this point is that as we use SIP/RTP-RTCP/RTSP as example to describe the NAT & FW requirements, having the ALG in the doc makes me think that I'm not too far from being authorized by the Midcom framework to "process" these bitstreams content. If the OPES WG is chartered, a framework enabling content processing would be one aspect of this WG work. Considering the OPES box as a "Content level middlebox" it will be interesting to see how it does cooperate w/ the MIDCOM box. Thanks Christian > -----Original Message----- > From: Scott Brim [mailto:sbrim@cisco.com] > Sent: Saturday, June 30, 2001 6:45 AM > To: Pyda Srisuresh > Cc: midcom@ietf.org > Subject: Re: [midcom] Out-of-Path Midcom Agents in framework-02 > > > On 25 Jun 2001 at 14:57 -0700, Pyda Srisuresh apparently wrote: > > --- Scott Brim wrote: > > > On 19 Jun 2001 at 13:11 -0700, Pyda Srisuresh apparently wrote: > > > > 1. Paragraph 1 of section 1 - Introduction > > > > > > > > "Application Level gateways (ALGs) are used in > conjunction with NAT > > > > to provide end-to-end transparency for many of the > applications." > > > > > > > > I think, it should be OK to leave this unchanged. > > > > > > OK, we're talking about application-layer transparency. > As long as you > > > mean that the application data and the application behavior are > > > unchanged, since that would fit the strict definition. I > think I agree. > > > > > > > ALG does not guarantee that application data is not > changed, even though > > its intention is to keep the application behaviour unchanged. > > It may in fact change the data in control payloads. So, the term > > "application level transparency" above doesnt meet the dictionary > > definition. > > > > Would the following rewording work for you? > > > > Application Level gateways (ALGs) are used in > conjunction with NAT > > to examine and optionally modify application payload so the > > end-to-end application behaviour remains unchanged for many > > of the applications traversing NAT middleboxes. > > Yes, thanks. > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 2 18:05:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19333 for ; Mon, 2 Jul 2001 18:05:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00868; Mon, 2 Jul 2001 18:01:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00842 for ; Mon, 2 Jul 2001 18:01:35 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16421 for ; Mon, 2 Jul 2001 18:00:50 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f62LxYr28928; Mon, 2 Jul 2001 14:59:34 -0700 (PDT) Received: from spandex (rtp-vpn-211.cisco.com [10.82.192.211]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AMK04300; Mon, 2 Jul 2001 14:59:20 -0700 (PDT) Message-ID: <004201c10342$64537340$d45904d1@cisco.com> From: "Melinda Shore" To: "Christian Huitema" , "Andrew Molitor" , References: Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Date: Mon, 2 Jul 2001 18:00:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > From: "Christian Huitema" > To: "Andrew Molitor" ; > Sent: Monday, July 02, 2001 5:46 PM > Subject: RE: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt > The group's membership > reflects its initial focus; extending the scope at this late hour is a > bad idea. More precisely, extending the scope at this late hour is not possible, period. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 2 18:12:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23611 for ; Mon, 2 Jul 2001 18:12:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01040; Mon, 2 Jul 2001 18:08:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01010 for ; Mon, 2 Jul 2001 18:08:33 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20934 for ; Mon, 2 Jul 2001 18:07:49 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f62M89r05263 for ; Mon, 2 Jul 2001 15:08:09 -0700 (PDT) Received: from spandex (rtp-vpn-211.cisco.com [10.82.192.211]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AMK04679; Mon, 2 Jul 2001 15:07:29 -0700 (PDT) Message-ID: <005001c10343$87fd4860$d45904d1@cisco.com> From: "Melinda Shore" To: Date: Mon, 2 Jul 2001 18:08:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Transfer-Encoding: 7bit Subject: [midcom] Showstoppers, August meeting agenda Sender: 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 August is nearly at our throats and I hope that we're coming into the home stretch on both documents. I think we need to identify showstoppers now rather than waiting for them to appear as we try to go to last call. From my perspective something that's absolutely, unequivocally a showstopper is anything in the documents that's out-of- scope. I've requested a 2.5-hour slot at the August meeting (and I know that people travelling from the west coast of the US will *really* appreciate a morning meeting). Right now I'm planning on using that time to thrash through outstanding issues for last call on both documents, but the more we can get done prior to the meeting the more time we can spend in London talking about futures. If you have other material you feel we should discuss during the meeting, please let me know. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 2 18:23:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01094 for ; Mon, 2 Jul 2001 18:23:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01323; Mon, 2 Jul 2001 18:20:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01291 for ; Mon, 2 Jul 2001 18:20:08 -0400 (EDT) Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28336 for ; Mon, 2 Jul 2001 18:19:24 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id D2AE88159 for ; Mon, 2 Jul 2001 17:20:07 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id RAA27189 for ; Mon, 2 Jul 2001 17:20:07 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Mon, 2 Jul 2001 17:20:07 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At risk of being boring and repetitive, let me quote myself: On Mon, 2 Jul 2001, Andrew Molitor wrote: > My personal opinion is that MIDCOM is the right place > to do this -- but I am also happy to concur that MIDCOM should table > that issue in favor of, say, getting something done now. Did this part get clipped off of the copy everyone else saw, or is it simply not clear that this means: 'I know QoS is out of scope and I agree that it doesn't go in the documents' That's what it does mean, for the record. Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 2 18:59:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24224 for ; Mon, 2 Jul 2001 18:59:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02225; Mon, 2 Jul 2001 18:55:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02200 for ; Mon, 2 Jul 2001 18:55:46 -0400 (EDT) Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21340 for ; Mon, 2 Jul 2001 18:55:04 -0400 (EDT) Received: from ns-ca.netscreen.com (ns-ca.netscreen.com [10.100.10.21]) by mail.netscreen.com (8.10.0/8.10.0) with ESMTP id f62MLOi17108; Mon, 2 Jul 2001 15:21:24 -0700 Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jul 2001 15:52:03 -0700 Message-ID: From: John LaCour To: "'Maciocco, Christian'" , midcom@ietf.org Cc: "'ietf-openproxy@imc.org'" Subject: RE: [midcom] Proxies / ALG in Midcom framework document Date: Mon, 2 Jul 2001 15:57:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > From: Maciocco, Christian [mailto:christian.maciocco@intel.com] > > While the Midcom framework scope is defined to be NAT & > Firewall in the > Introduction chapter I think that describing Proxies and > especially ALG > later in the doc is confusing about this WG charter. There > have been a lot > of "proposed extension" lately, e.g. QoS support, OOP w/ > packets diversion, > etc. We should make sure to focus the document to transport > level issues > only. Its not clear to me whether or not the MIDCOM group is chartered to be concerned ONLY about middleboxes which affect or care about layers 3 and 4. It is clear to me that MIDCOM appears to have chosen to focus on packet filters and NAT initially. Will we extend the scope of the wg to additional layer 3 and 4 middlebox functions or other functions in other layers as well? I have a middlebox that enforces policies based on layers 2 through 7. I'd like to minimize the number of MIDCOM-like protocols I have to deal with without losing the ability for trusted application agents to tell me how to help them manage/mangle/manipulate data at the relevant layer. -John LaCour _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 3 08:42:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00939 for ; Tue, 3 Jul 2001 08:42:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04926; Tue, 3 Jul 2001 08:31:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04897 for ; Tue, 3 Jul 2001 08:31:14 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA23798 for ; Tue, 3 Jul 2001 08:30:29 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f63CUix05990; Tue, 3 Jul 2001 05:30:44 -0700 (PDT) Received: from spandex (rtp-vpn-189.cisco.com [10.82.192.189]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AML05547; Tue, 3 Jul 2001 05:30:34 -0700 (PDT) Message-ID: <027901c103bc$1ab09680$d45904d1@cisco.com> From: "Melinda Shore" To: "John LaCour" , Cc: References: Subject: Re: [midcom] Proxies / ALG in Midcom framework document Date: Tue, 3 Jul 2001 08:31:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > From: "John LaCour" > To: "'Maciocco, Christian'" ; > Cc: > Sent: Monday, July 02, 2001 6:57 PM > Subject: RE: [midcom] Proxies / ALG in Midcom framework document > Its not clear to me whether or not the MIDCOM group is chartered > to be concerned ONLY about middleboxes which affect or care > about layers 3 and 4. We are. We're trying to solve a pressing problem with firewall and NAT traversal. We're trying to do it in a manner that may generalize well to other middlebox-type problems, but we do have a very specific piece of work in front of us at this time. The question of our relationship with groups doing application-layer middlebox interfaces remains open, in no small part because this work is so new. I believe that there are plans to discuss what midcom is doing and how it relates to OPES at the OPES session during the August meeting. We can discuss it on the mailing list prior to that, obviously. As we start to think about rechartering and as charter/scope issues continue to crop up on the mailing list it might be worth considering 1) what a next rev. of a midcom working group might look like, and 2) how people interested in using midcom for something else (QoS, packet diversion) might proceed. My *personal* opinion and my personal preference is that if we are rechartered it will be specifically to do protocol development for an interface to firewalls and NATs. We are not here to solve every problem related to middleboxes in the network. However, if we do a good job and the framework is correct and useful, it may be that other work is proposed to the IETF based on our framework, and that work will have to go through the chartering and review process on its own. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 3 08:47:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04352 for ; Tue, 3 Jul 2001 08:47:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05262; Tue, 3 Jul 2001 08:41:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05228 for ; Tue, 3 Jul 2001 08:41:15 -0400 (EDT) Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29502 for ; Tue, 3 Jul 2001 08:40:28 -0400 (EDT) From: richard.swale@bt.com Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Tue, 3 Jul 2001 13:39:39 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Tue, 3 Jul 2001 13:39:16 +0100 Message-ID: To: brian@hursley.ibm.com, sanjoy@nortelnetworks.com Cc: bpenfield@acmepacket.com, midcom@ietf.org Subject: RE: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Date: Tue, 3 Jul 2001 13:31:23 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Brian, > > > > > > Being able to set the DS code point is definitely something that > > > applications are going to want to do. For example, a SIP > > > proxy acting as a > > > midcom agent talking to a middlebox at the border between > > > networks will need > > > to instruct the middlebox to set the DSCP in the RTP packets > > > that will flow > > > thru the middlebox. The RTP packets will not flow thru the > > > SIP proxy/midcom > > > agent. The middlebox is the only place the application > will be able to > > > affect QoS for the data flows. > > > > > > > Or, the SIP Proxy (MA) may be able to engage a PDP to set > the DS filters in the Middlebox. Does this mean that we may also > > need to define, in future, an interface between the MA and the PDP? > > We won't be changing QOS policy on a per-call basis, so I don't see > why that would be needed. > > Brian > The settings of DS bits, or TOS bits _may_ have different meanings on either side of a Middlebox (i.e. where it is firewalling between two networks). In such cases it may be necessary for a MIDCOM Agent to request a Middlebox to apply a specific mapping to a specific flow traversing the Middlebox. This is a definite requirement and is IMHO certainly within the scope of MIDCOM to allow. End-end signalling for QoS is a different matter altogether and so clearly out of scope. regards Richard _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 3 09:13:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20446 for ; Tue, 3 Jul 2001 09:13:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06550; Tue, 3 Jul 2001 09:05:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06516 for ; Tue, 3 Jul 2001 09:05:43 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15104 for ; Tue, 3 Jul 2001 09:04:58 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f63D5Bh21951; Tue, 3 Jul 2001 06:05:11 -0700 (PDT) Received: from spandex (rtp-vpn-300.cisco.com [10.82.193.44]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AML05891; Tue, 3 Jul 2001 06:05:06 -0700 (PDT) Message-ID: <003401c103c0$ed8b0640$d45904d1@cisco.com> From: "Melinda Shore" To: Cc: References: Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Date: Tue, 3 Jul 2001 09:06:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > From: > To: ; > Cc: ; > Sent: Tuesday, July 03, 2001 8:31 AM > Subject: RE: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt > End-end signalling for QoS is a different matter altogether and so > clearly out of scope. Any QoS signaling is out of scope. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 3 11:04:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28186 for ; Tue, 3 Jul 2001 11:04:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11008; Tue, 3 Jul 2001 10:56:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10978 for ; Tue, 3 Jul 2001 10:56:48 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23113 for ; Tue, 3 Jul 2001 10:56:03 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA24178; Tue, 3 Jul 2001 15:56:16 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA52362; Tue, 3 Jul 2001 15:56:14 +0100 Message-ID: <3B41DCF5.17B69A09@hursley.ibm.com> Date: Tue, 03 Jul 2001 09:55:49 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: richard.swale@bt.com CC: sanjoy@nortelnetworks.com, bpenfield@acmepacket.com, midcom@ietf.org Subject: Re: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Richard (and Andrew Molitor, to clarify what I meant), Indeed a midcom middlebox can apply diffserv traffic conditioning, and the diffserv regime can be different downstream from upstream (in which case the midcom middlebox is at a diffserv domain boundary). But this applies to diffserv traffic aggregates, not to individual flows, as does everything in diffserv. We can't be changing the parameters of a traffic aggregate each time a flow starts & stops. Now, if you mean that when a new flow starts (and stops), the diffserv classifier in the midcom middlebox needs to be told the relevant 5-tuple so that it can create (and destroy) a classifier for that flow, that I can see, but it's the only scaleable flow-specific change I can imagine. Regards Brian richard.swale@bt.com wrote: > > Brian, > > > > > > > > > Being able to set the DS code point is definitely something that > > > > applications are going to want to do. For example, a SIP > > > > proxy acting as a > > > > midcom agent talking to a middlebox at the border between > > > > networks will need > > > > to instruct the middlebox to set the DSCP in the RTP packets > > > > that will flow > > > > thru the middlebox. The RTP packets will not flow thru the > > > > SIP proxy/midcom > > > > agent. The middlebox is the only place the application > > will be able to > > > > affect QoS for the data flows. > > > > > > > > > > Or, the SIP Proxy (MA) may be able to engage a PDP to set > > the DS filters in the Middlebox. Does this mean that we may also > > > need to define, in future, an interface between the MA and the PDP? > > > > We won't be changing QOS policy on a per-call basis, so I don't see > > why that would be needed. > > > > Brian > > > > The settings of DS bits, or TOS bits _may_ have different meanings on either > side of a Middlebox (i.e. where it is firewalling between two networks). In > such cases it may be necessary for a MIDCOM Agent to request a Middlebox to > apply a specific mapping to a specific flow traversing the Middlebox. This > is a definite requirement and is IMHO certainly within the scope of MIDCOM > to allow. End-end signalling for QoS is a different matter altogether and so > clearly out of scope. > > regards > > Richard _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 3 17:34:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10217 for ; Tue, 3 Jul 2001 17:34:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24692; Tue, 3 Jul 2001 17:27:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24661 for ; Tue, 3 Jul 2001 17:26:59 -0400 (EDT) Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04816 for ; Tue, 3 Jul 2001 17:26:14 -0400 (EDT) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id TAA26574; Tue, 3 Jul 2001 19:43:26 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 03 Jul 2001 19:43:16 0000 (GMT) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by fmsmsx19.fm.intel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NKZVF349; Tue, 3 Jul 2001 12:43:13 -0700 Received: from condryvaio-mobl.intel.com ([134.134.159.55]) by 132.233.42.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 03 Jul 2001 19:43:13 0000 (GMT) Message-Id: <5.1.0.14.2.20010703124134.05842d38@FMSMSX63.intel.com> X-Sender: mwcondry@FMSMSX63.intel.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Jul 2001 12:41:48 -0700 To: "Melinda Shore" , "John LaCour" , From: "Michael W. Condry" Subject: Re: [midcom] Proxies / ALG in Midcom framework document Cc: In-Reply-To: <027901c103bc$1ab09680$d45904d1@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org group cooperation is good for all of us. At 08:31 AM 7/3/2001 -0400, Melinda Shore wrote: > > From: "John LaCour" > > To: "'Maciocco, Christian'" ; > > > Cc: > > Sent: Monday, July 02, 2001 6:57 PM > > Subject: RE: [midcom] Proxies / ALG in Midcom framework document > > > > Its not clear to me whether or not the MIDCOM group is chartered > > to be concerned ONLY about middleboxes which affect or care > > about layers 3 and 4. > >We are. We're trying to solve a pressing problem with firewall >and NAT traversal. We're trying to do it in a manner that may >generalize well to other middlebox-type problems, but we do have >a very specific piece of work in front of us at this time. The >question of our relationship with groups doing application-layer >middlebox interfaces remains open, in no small part because this >work is so new. I believe that there are plans to discuss what >midcom is doing and how it relates to OPES at the OPES session >during the August meeting. We can discuss it on the mailing >list prior to that, obviously. > >As we start to think about rechartering and as charter/scope issues >continue to crop up on the mailing list it might be worth >considering 1) what a next rev. of a midcom working group might >look like, and 2) how people interested in using midcom for something >else (QoS, packet diversion) might proceed. My *personal* opinion >and my personal preference is that if we are rechartered it will be >specifically to do protocol development for an interface to firewalls >and NATs. We are not here to solve every problem related to >middleboxes in the network. However, if we do a good job and >the framework is correct and useful, it may be that other work >is proposed to the IETF based on our framework, and that work will >have to go through the chartering and review process on its own. > >Melinda Michael W. Condry Director, Network Edge Technology _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 3 23:32:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA13392 for ; Tue, 3 Jul 2001 23:32:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04541; Tue, 3 Jul 2001 23:24:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04511 for ; Tue, 3 Jul 2001 23:24:41 -0400 (EDT) Received: from obsoft.com (sdsl-208-185-238-35.dsl.sjc.megapath.net [208.185.238.35]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12965 for ; Tue, 3 Jul 2001 23:23:55 -0400 (EDT) Received: from obsoft.com (IDENT:sardana@localhost.localdomain [127.0.0.1]) by obsoft.com (8.9.3/8.9.3) with ESMTP id UAA19508; Tue, 3 Jul 2001 20:28:22 -0700 Message-ID: <3B428D56.EC8F3279@obsoft.com> Date: Tue, 03 Jul 2001 20:28:22 -0700 From: Bobby Sardana Organization: ObjectSoftware, Inc X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Melinda Shore CC: John LaCour , midcom@ietf.org, ietf-openproxy@imc.org Subject: Re: [midcom] Proxies / ALG in Midcom framework document References: <027901c103bc$1ab09680$d45904d1@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Greetings: So what happens to all the application layer protocols (SIP,HTTP) who have their own means of firewall traversal? Will they have to comply to the MIDCOM specification once it is published? Regards, Bobby Sardana. sardana@obsoft.com Melinda Shore wrote: > > From: "John LaCour" > > To: "'Maciocco, Christian'" ; > > Cc: > > Sent: Monday, July 02, 2001 6:57 PM > > Subject: RE: [midcom] Proxies / ALG in Midcom framework document > > > Its not clear to me whether or not the MIDCOM group is chartered > > to be concerned ONLY about middleboxes which affect or care > > about layers 3 and 4. > > We are. We're trying to solve a pressing problem with firewall > and NAT traversal. We're trying to do it in a manner that may > generalize well to other middlebox-type problems, but we do have > a very specific piece of work in front of us at this time. The > question of our relationship with groups doing application-layer > middlebox interfaces remains open, in no small part because this > work is so new. I believe that there are plans to discuss what > midcom is doing and how it relates to OPES at the OPES session > during the August meeting. We can discuss it on the mailing > list prior to that, obviously. > > As we start to think about rechartering and as charter/scope issues > continue to crop up on the mailing list it might be worth > considering 1) what a next rev. of a midcom working group might > look like, and 2) how people interested in using midcom for something > else (QoS, packet diversion) might proceed. My *personal* opinion > and my personal preference is that if we are rechartered it will be > specifically to do protocol development for an interface to firewalls > and NATs. We are not here to solve every problem related to > middleboxes in the network. However, if we do a good job and > the framework is correct and useful, it may be that other work > is proposed to the IETF based on our framework, and that work will > have to go through the chartering and review process on its own. > > Melinda > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jul 4 03:09:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01500 for ; Wed, 4 Jul 2001 03:09:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20218; Wed, 4 Jul 2001 02:58:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20187 for ; Wed, 4 Jul 2001 02:58:51 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00764 for ; Wed, 4 Jul 2001 02:58:07 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f646wKw24209 for ; Wed, 4 Jul 2001 07:58:20 +0100 (BST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Wed, 4 Jul 2001 07:57:54 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <3HB6Z152>; Wed, 4 Jul 2001 07:57:53 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C3044505D@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'Andrew Molitor'" Cc: midcom@ietf.org Subject: RE: [midcom] Re: I-D ACTION:draft-ietf-midcom-framework-02.txt Date: Wed, 4 Jul 2001 07:57:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10456.A5632000" Sender: 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_01C10456.A5632000 Content-Type: text/plain; charset="iso-8859-1" Sorry if I'm repeating things that other WG members already mentioned ... "It is clearly desirable to allow something like a SIP Proxy server to actively provision network elements with QoS/bandwidth parameters.." Andrew I totally agree with you, but we need to stick with delivering the framework and protocol requirements for a protocol that allows negotiation and control of Packet filtering and NAT Middle Box functions. Within these 2 documents (we should express that the protocol could be easily extended to control other Middle Box functions(Qos and others, this is already mentioned in the documents). In case we fail to deliver our current expected work items, we won't be re-chartered to start going into the protocol spec work and try to find an existing protocol (with probably some extensions) that will meet the MIDCOM protocol requirements. After being re-charted we need to see how we could get Qos and other functions to be handled by MIDCOM. Thanks Cedric _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C10456.A5632000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Re: I-D = ACTION:draft-ietf-midcom-framework-02.txt

Sorry if I'm repeating things that other WG members = already mentioned ...

"It is clearly desirable to allow something like = a SIP Proxy
server to actively provision network elements with = QoS/bandwidth
parameters.."

Andrew I totally agree with you, but we need to stick = with delivering the framework
and protocol requirements for a protocol that allows = negotiation and control of
Packet filtering and NAT Middle Box functions. = Within these 2 documents (we
should express that the protocol could be easily = extended to control other Middle
Box functions(Qos and others, this is already = mentioned in the documents).

In case we fail to deliver our current expected work = items, we won't be
re-chartered to start going into the protocol spec = work and try to find an existing protocol
(with probably some extensions) that will meet the = MIDCOM protocol requirements.
After being re-charted we need to see how we could = get Qos and other functions to be
handled by MIDCOM.
Thanks
Cedric



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

------_=_NextPart_001_01C10456.A5632000-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jul 4 08:51:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05874 for ; Wed, 4 Jul 2001 08:51:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02451; Wed, 4 Jul 2001 08:43:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02423 for ; Wed, 4 Jul 2001 08:43:12 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05734 for ; Wed, 4 Jul 2001 08:42:26 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f64CesH05082; Wed, 4 Jul 2001 05:40:55 -0700 (PDT) Received: from spandex (rtp-vpn-156.cisco.com [10.82.192.156]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AMU01738; Wed, 4 Jul 2001 05:42:32 -0700 (PDT) Message-ID: <014101c10486$f1520e60$d45904d1@cisco.com> From: "Melinda Shore" To: "Bobby Sardana" Cc: , References: <027901c103bc$1ab09680$d45904d1@cisco.com> <3B428D56.EC8F3279@obsoft.com> Subject: Re: [midcom] Proxies / ALG in Midcom framework document Date: Wed, 4 Jul 2001 08:43:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > So what happens to all the application layer protocols (SIP,HTTP) who have their > own means of firewall traversal? Will they have to comply to the MIDCOM > specification once it is published? I don't know of any protocol that has its own means of firewall traversal. Firewalls may or may not have support for particular protocols. That won't change, of course, and firewalls that do stateful inspection will continue to be useful in cases where there's no application support for midcom or when performance and application security are not issues. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 5 14:14:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22215 for ; Thu, 5 Jul 2001 14:14:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03487; Thu, 5 Jul 2001 13:53:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03457 for ; Thu, 5 Jul 2001 13:53:48 -0400 (EDT) Received: from web13805.mail.yahoo.com (web13805.mail.yahoo.com [216.136.175.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21612 for ; Thu, 5 Jul 2001 13:53:02 -0400 (EDT) Message-ID: <20010705175346.89829.qmail@web13805.mail.yahoo.com> Received: from [65.12.33.187] by web13805.mail.yahoo.com; Thu, 05 Jul 2001 10:53:46 PDT Date: Thu, 5 Jul 2001 10:53:46 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [midcom] Framework draft review To: "'midcom@ietf.org'" Cc: Sanjoy Sen , Mary Barnes In-Reply-To: <85AA7486A2C1D411BCA20000F8073E43016BBFA8@crchy271.us.nortel.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 --- Sanjoy Sen wrote: > > > Here're some feedback from myself & Mary Barnes on the Framework draft. > Please find our comments within the delimiters, such as [SS] and [/SS]. > > Regards, > Sanjoy > Thanks. Sorry about the delay in responding. > ======================= > 1. Introduction > ---------------- > > 3rd sentence: Network Address Translator service, on the other hand, > provides routing transparency across address realms (within IPv4 routing > network or across V4 and V6 routing realms). Application Level gateways > (ALGs) are used in conjunction with NAT to provide end-to-end transparency > for many of the applications. > > [MB] I think this has already been discussed before, but transparency is not > a term here for either of these sentences. I would suggest rewording these > 2 sentences as: > > The address mapping of Network Address Translation (within IPv4 routing > network or across V4 and V6 routing realms), however, is independent from > the end application. An Application Level Gateway (ALG) used in conjunction > with NAT can remove the knowledge of NATs for applications for which NATs > are problematic. [/MB] > I believe, I addressed this in a different thread with Brian Carpenter and Scott Brim. Thanks. > 2.5. Proxy > > A proxy is an intermediate relay agent between clients and servers > of an application, relaying application messages between the two. > Proxies use special protocol mechanisms to communicate with proxy > clients and relay client data to servers and vice versa. > > [SS] The proxies described here are application layer proxies. There're > other types of proxies which relays the transport stream (Transport layer > proxies), such as an RTP proxy, without higher layer application awareness. > These two types should perhaps be distinguished. The reason is that while > application layer proxies can be a type of Midcom agent, the transport layer > proxies can be a type of Middle-Box (and I think that Midcom is a general > framework with the eventual goal of addressing all kinds of Middleboxes). > Proxies which are application-unaware but need application-specific > intelligence are also Middle-boxes. [/SS] > You are right. Some proxies can be application unaware. But, all Proxy clients (i.e., applications using proxy servers) are aware of proxies. In any case, the description in the document is not restricted to application specific proxies, as you claim. > > 2.8. MIDCOM Agents > > MIDCOM agents are entities performing ALG function, ... > > [SS] Why only ALG's? Application layer proxies (since you've distinguished > between ALG's & proxies) can also be Midcom agents, as you've provided some > examples in the next paragraph. [/SS] > > The protocol will allow MIDCOM agents to signal > the middleboxes to let complex applications using dynamic port > based sessions through them (i.e., middleboxes) seamlessly. > > [SS] There are additional protocol requirements which may need to be > addressed here (or perhaps in the Requirements draft), such as the > following. The protocol should allow exchange of state synchronization > information (such as resource availability, state of the binding in case > NAT's, health-checks etc) between the Midcom Agent & the Middle-box. The > protocol should also allow modification of state in the Middle-box during > runtime. The protocol should be able to specify direction of the connection > through the Middle-box. [/SS] > These are protocol Requirements. Not addressed here. > Connection setup must be preceded by registration of the > MIDCOM agent with either the middlebox or the Policy Server. > > [SS] There might be situations where this registration process is initiated > by the Middle-box itself. So, isn't it better to phrase the above sentence > as "Connection set-up must be preceded by a registration phase between the > Midcom agent and either the Middle-box or the Policy server". This also > concurrs more with the text in the Protocol Requirements DRAFT. [/SS] > I belive, the text as it exists, reads fine. Registration here specifically refers to registration of MIDCOM agents. > Alternately, a MIDCOM session termination may be triggered by > one of (a) agent going out of service and not being available > for further MIDCOM operations, .... > > [SS] It would also be triggered by the Middle-box going out of service. > [/SS] > Sure. I will fix the text to reflect this. Thanks. > During connection establishment, an agent would identify > itself as either In-Path or Out-Of-Path(OOP) to the middlebox. > > [SS] This should be during Registration phase, right? > Is support of OOP Midcom agent (& the associated "diversion" function in the > Middle-box), mandatory under the framework or is it optional? This should be > mentioned too. [/SS] > The document will be revised to remove discussion on OOP agents. > Profile of a MIDCOM agent includes agent authorization policy (i.e, > session tuples for which the agent is authorized to act as ALG), ... > > [SS] Please define Session Tuple. If its the Session id address/port, protocol>, then in many cases, the MA doesn't know about it > until the session is being initiated (e.g., SIP session). It may not be > possible for the MA to have this information during the time of > registration. [/SS] > > 4. MIDCOM Protocol > > [MB] Initially, I was in agreement with Eric Fleishman's comments that the > last 2 paragraphs of Section 4 are misplaced as they describe functionality > of the Middlebox (stateful vs. stateless) rather than the protocol itself. > However, in re-reading, I think that the concept is also protocol related > (i.e. which messages effect a change in the Protocol state machine). > Perhaps, there needs to be a paragraph in Section 3 such as: > > Some middlebox services are stateless. However, there are many that > are stateful and maintain per-connection state in the system. > Firewall service may be implemented as a stateless list of ACLs. > Many firewall implementations, however, are stateful. NAT > service, on the other hand, is inherently stateful. As such, > support of the MIDCOM protocol will require a middlebox to be > stateful. Refer to Section 4.0 for further detail. > > And a paragraph in Section 4 (replacing the current last 2 paragraphs) that > reads something like: > > The MIDCOM protocol may require a middlebox to be > stateful. For the case of a middlebox implementing firewall > service, with the advent of MIDCOM protocol, the middlebox is > required to allocate dynamic resources, such as pin-holes, > upon request from agents. Explicit release of dynamically > allocated resources happens when the application session is > ended or when a Midcom agent requests the middlebox to release > the resource. However, the middlebox must be able to recover the > dynamically allocated resources at some point in time even if > the agent that was responsible for the dynamic allocation is not > alive. Typically, this is done by tracking the state of each > dynamically allocated pin-hole with some type of a timer. > This exemplifies that even the firewall function will need to > maintain per-connection state, as a requirement to support the > MIDCOM protocol. > > [/MB] > I will remove both these paragraphs from the document and simply add a section titled "Timers on Middlebox considered useful" in the Operational Considerations section. > > The technique described above is necessary for the pre-registration of > MIDCOM agents with the > Middlebox. However, it is possible to retain the provisioning on > middlebox unchanged, by > requiring MIDCOM agents to initiate the connection to middlebox. In such > a case, the > agent should initiate the connection prior to the start of the > application. ... > > > [SS] I assume that you're talking about Registration connection here. How > does the Midcom agent know when to initiate this connection? Again, going > back to the SIP example, the agent can only initiate the connection on > receipt of a SIP INVITE message. It makes sense to me for apriori > registration between the MB & MA, & MA be ready for connection set-up > whenever required. The registration is refreshed periodically. [/SS] That may very well be the case. (i.e., apriori connection between MB and MA). > > [SS] Typo in the third line of last para of page 20 - "... media stream, > When used" [/SS] > What is the typo? > Section 7.3 - Middlebox implementing NAPT & Firewall call flows: > > | | | | > | |++Permit RTP1 & RTCP1 | | > | | sessions External to| | > | | middlebox, namely | | > | | Ma to Ea:Eport1, | | > | | Ma to Ea:Eport1+1 | | > | | sessions ++++++++++>| | > | |<+Ma to Ea:Eport1, | | > | | Ma to Ea:Eport1+1 | | > | | sessions OKed ++++++| > > > [SS] Should this be Ma or is it Pa? > It is Ma. > For certain types of NAPT, you won't be able to complete the binding & > update the NAPT table until you know the port address of the callee, which > is not part of the SDP in INVITE. In many cases, the SDP of the callee > (containing the port) is carried in the provisional response 180/183, and > Early Media follows the provisional response. The MA should be able to > complete the NAPT binding based on the SDP of the callee in the response > message, to allow early media. [/SS] > In order for the early media messages to reach the caller, it should be OK to open UDP sessions from any port of the callee to caller. > 9.3. Asynchronous notification to MIDCOM agents > > Asynchronous notification by the middlebox to a MIDCOM agent > can be useful for events such as Session creation, Session > termination, MIDCOM protocol failure, Middlebox function > failure or any other significant event. Independently, ICMP > error codes can also be useful to notify transport layer > failures to the agents. ... > > [SS] We should perhaps also include the following: > - Exchange state synchronization information (described earlier) > - Periodic health check message exchange Please see my comments above about creating a new section titled "Timers on Middlebox considered useful". > - MB send logs of unauthorized access & unsolicitated alarms to the > MA This sounds like generic middlebox managment/monitoring requirement. Not sure, this is MA specific. In any case, I believe, mention of "periodic notification of various forms of data such as statistics update" would cover any specific cases that may be required by an MA. > [/SS] > > Regards, > Sanjoy Sen > Thanks. cheers, suresh ===== __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jul 6 12:00:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09790 for ; Fri, 6 Jul 2001 12:00:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20841; Fri, 6 Jul 2001 11:42:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20806 for ; Fri, 6 Jul 2001 11:41:58 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08874 for ; Fri, 6 Jul 2001 11:41:07 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f66FdeH26359 for ; Fri, 6 Jul 2001 08:39:41 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-254.cisco.com [10.82.192.254]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ANG02538; Fri, 6 Jul 2001 08:41:18 -0700 (PDT) Message-Id: <5.1.0.14.0.20010706113523.009edaf0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Jul 2001 11:42:19 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] London meeting time Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org We're tentatively scheduled to meet from 9-1130 on Thursday, 9 August. Also scheduled at that time are: APP trade Internet Open Trading Protocol WG OPS rap-II Resource Allocation Protocol WG SEC sacred Securely Available Credentials WG SUB-IP tewg Internet Traffic Engineering WG TSV avt-II Audio/Video Transport WG At the top of the agenda are wrapping up those things which need to be wrapped in the framework document and the requirements document. Please let me know if there's anything you feel *must* be addressed in the meeting beyond work on the documents. Note, however, that it would be very, very, very much appreciated if issues could be raised on the mailing list ahead of time - the meeting is not *the* place where work is done, but one place among several. The bulk of the work is done on mailing lists, and that's where consensus is developed. Also, as we prepare to go into last call on the framework document, do raise issues as soon as you become aware of them rather than waiting until the last minute and gumming up the process. Many thanks. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jul 6 12:31:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11602 for ; Fri, 6 Jul 2001 12:30:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22318; Fri, 6 Jul 2001 12:14:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22282 for ; Fri, 6 Jul 2001 12:14:13 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10576 for ; Fri, 6 Jul 2001 12:13:26 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f66G7WH09602; Fri, 6 Jul 2001 09:11:48 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn1-12.cisco.com [10.21.96.12]) by airborne.cisco.com (Mirapoint) with ESMTP id AFJ09572; Fri, 6 Jul 2001 09:09:10 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15173.58021.800000.530129@gargle.gargle.HOWL> Date: Fri, 6 Jul 2001 12:09:09 -0400 To: Pyda Srisuresh Cc: "'midcom@ietf.org'" , Sanjoy Sen , Mary Barnes Subject: RE: [midcom] Framework draft review In-Reply-To: <20010705175346.89829.qmail@web13805.mail.yahoo.com> References: <85AA7486A2C1D411BCA20000F8073E43016BBFA8@crchy271.us.nortel.com> <20010705175346.89829.qmail@web13805.mail.yahoo.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit On 5 Jul 2001 at 10:53 -0700, Pyda Srisuresh apparently wrote: > --- Sanjoy Sen wrote: > > ======================= > > 1. Introduction > > ---------------- > > > > 3rd sentence: Network Address Translator service, on the other hand, > > provides routing transparency across address realms (within IPv4 routing > > network or across V4 and V6 routing realms). Application Level gateways > > (ALGs) are used in conjunction with NAT to provide end-to-end transparency > > for many of the applications. > > > > [MB] I think this has already been discussed before, but transparency is not > > a term here for either of these sentences. I would suggest rewording these > > 2 sentences as: > > > > The address mapping of Network Address Translation (within IPv4 routing > > network or across V4 and V6 routing realms), however, is independent from > > the end application. An Application Level Gateway (ALG) used in conjunction > > with NAT can remove the knowledge of NATs for applications for which NATs > > are problematic. [/MB] > > > > I believe, I addressed this in a different thread with Brian Carpenter > and Scott Brim. Thanks. Actually we didn't reach agreement. I dropped it because I felt that it wasn't productive to pursue it when we had much bigger issues to deal with, like requirements. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jul 6 18:42:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22485 for ; Fri, 6 Jul 2001 18:42:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03328; Fri, 6 Jul 2001 18:36:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03295 for ; Fri, 6 Jul 2001 18:36:29 -0400 (EDT) Received: from nemo.corp.equinix.com (somehost-3.equinix.net [207.20.85.155]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22338 for ; Fri, 6 Jul 2001 18:35:42 -0400 (EDT) From: hardie@equinix.com Received: (from hardie@localhost) by nemo.corp.equinix.com (8.9.3/8.9.3) id PAA03074; Fri, 6 Jul 2001 15:33:43 -0700 (PDT) Message-Id: <200107062233.PAA03074@nemo.corp.equinix.com> To: midcom@ietf.org Date: Fri, 6 Jul 2001 15:33:43 -0700 (PDT) Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Firewall interaction with BEEP Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit As many of you may know, beep is an application protocol framework standardized within the IETF as a method for reusing common protocol elements for connection-oriented application protocols (see RFCs 3080 and 3081 for the core specs and the mapping onto TCP). Thinking about how beep works, it occured to me that there might be a requirement for MIDCOM agents to refer to specific protocols layered on top of beep. With his permission, I've attached below an email response from Marshall Rose on the issue; his basic message is that an effective message to a firewall about a beep connection will need a tuple of (src, dest, profiles) to cover the policy requirements. On the positive side, as he notes, all elements of a beep session are currently bound to a single TCP connection and there are not FTP-data type problems to contend with. Despite there being no current firewall applications that are beep capable, I believe we may need language in the requirements document to cover the use of profiles within beep sessions. regards, Ted Hardie >From mrose@dbc.mtview.ca.us Fri Jul 6 12:33:01 2001 >> Do you have any information on how current firewall configurations >> handle beep's ability to handle multiple applications, and do you have >> a sense of whether src,dest,application is a sufficient tuple for the >> applicationof firewall logic? >hi. i'm not aware of any firewalls that are beep capable. that's probably >because the first set of beep applications haven't rolled out yet, and most >firewall vendors operate in a reactive mode with respect to the market. >at a first cut, a tuple of is adequate. >this is a bit different that what you suggest, for two reasons. >first, i use the term "profile" rather than "application", since this is the >term that beep knows about and exchanges. that is, a firewall could be >figured to allow traffic from a particular src/dst pair, if it looked like >beep, but only if profiles from allowed list were started. >second, i use the plural "profiles" because you may want more than one. for >example, the first thing the peers might do is start up a sasl channel for >authentication, and then they might start one or more data channels for >exchange. >there is one nuance to all this: if the TLS profile (or a SASL profile that >does privacy in addition to authentication) is on the allowed list, then the >firewall is going to lose the ability to observe traffic. the same is true >if the tunnel profile from the idxp working group is on the allowed list. >maybe this is an okay thing, it's up to the administrator to setup the list >of acceptable profiles to start. >of course, things like APEX imply the same kind of issues that you'd find >with allowing SMTP traffic; similarly, things like SOAP imply the same kind >of issues that you'd find with allowing HTTP traffic. >on the bright side, since all the traffic for a beep session is currently >bound to a single tcp session, you don't have the ftp-data/h.323 issue. >hope that helps. >/mtr _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jul 6 22:22:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26712 for ; Fri, 6 Jul 2001 22:22:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA08514; Fri, 6 Jul 2001 22:15:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA08451 for ; Fri, 6 Jul 2001 22:15:09 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26514 for ; Fri, 6 Jul 2001 22:14:22 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f672CcP14689; Fri, 6 Jul 2001 19:12:38 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn2-16.cisco.com [10.21.112.16]) by airborne.cisco.com (Mirapoint) with ESMTP id AFP00276; Fri, 6 Jul 2001 19:12:29 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 Q); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15174.24053.637000.999121@gargle.gargle.HOWL> Date: Fri, 6 Jul 2001 20:55:17 -0400 To: "Maciocco, Christian" Cc: midcom@ietf.org, "'ietf-openproxy@imc.org'" Subject: Re: [midcom] Proxies / ALG in Midcom framework document In-Reply-To: References: Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit On 2 Jul 2001 at 14:58 -0700, Maciocco, Christian apparently wrote: > The concern I have if we describe ALG in this doc at this point is that as > we use SIP/RTP-RTCP/RTSP as example to describe the NAT & FW requirements, > having the ALG in the doc makes me think that I'm not too far from being > authorized by the Midcom framework to "process" these bitstreams content. If > the OPES WG is chartered, a framework enabling content processing would be > one aspect of this WG work. Considering the OPES box as a "Content level > middlebox" it will be interesting to see how it does cooperate w/ the MIDCOM > box. What you do in a Midcom "agent" is completely out of scope for Midcom. Midcom cares about how the agent controls the behavior (in particular the NAT/Firewall behavior) of the middlebox functions. You can manipulate content all you want and the midcom protocol won't ever hear about it. If you want some protocol that communicates how content is or should be manipulated, that's where you talk to OPES. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jul 6 22:22:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26726 for ; Fri, 6 Jul 2001 22:22:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA08509; Fri, 6 Jul 2001 22:15:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA08450 for ; Fri, 6 Jul 2001 22:15:09 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26513 for ; Fri, 6 Jul 2001 22:14:22 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f672CXx24369; Fri, 6 Jul 2001 19:12:33 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn2-16.cisco.com [10.21.112.16]) by airborne.cisco.com (Mirapoint) with ESMTP id AFP00271; Fri, 6 Jul 2001 19:12:19 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 Q); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15174.23029.140000.335102@gargle.gargle.HOWL> Date: Fri, 6 Jul 2001 20:38:13 -0400 To: Brian E Carpenter Cc: Cedric Aoun , "'Bob Penfield'" , "Midcom IETF (E-mail)" Subject: Re: [midcom] Re: draft-ietf-midcom-requirements-01.txt In-Reply-To: <3B4088B2.481DDEEA@hursley.ibm.com> References: <9154CB41F208D5118DD200508BE39C3044504E@zjguc006.europe.nortel.com> <3B4088B2.481DDEEA@hursley.ibm.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit On 2 Jul 2001 at 09:44 -0500, Brian E Carpenter apparently wrote: > I still object to QOS being shown as a fundamental part of the midcom model, > although I agree that we should not close the door in the design. Right, exactly. There is no reason for midcom to mention QoS, as long as the requirements draft clearly says the midcom protocol must be extensible. Bundling in instructions on diffserv markings would be a simple extension, just as it is for COPS or RSVP. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jul 6 22:29:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26843 for ; Fri, 6 Jul 2001 22:29:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA08642; Fri, 6 Jul 2001 22:22:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA08608 for ; Fri, 6 Jul 2001 22:22:07 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26671 for ; Fri, 6 Jul 2001 22:21:20 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f672LhP17288; Fri, 6 Jul 2001 19:21:43 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn2-16.cisco.com [10.21.112.16]) by airborne.cisco.com (Mirapoint) with ESMTP id AFP00334; Fri, 6 Jul 2001 19:21:35 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15174.29232.149000.544611@gargle.gargle.HOWL> Date: Fri, 6 Jul 2001 22:21:36 -0400 To: hardie@equinix.com Cc: midcom@ietf.org Subject: Re: [midcom] Firewall interaction with BEEP In-Reply-To: <200107062233.PAA03074@nemo.corp.equinix.com> References: <200107062233.PAA03074@nemo.corp.equinix.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit On 6 Jul 2001 at 15:33 -0700, hardie@equinix.com apparently wrote: > Despite there being no current firewall applications that are > beep capable, I believe we may need language in the requirements > document to cover the use of profiles within beep sessions. I think this comes down to a statement that the midcom protocol syntax needs to be flexible enough to do not just what we are focused on right now, but what others might need to do in the future -- we already have this covered -- and that we should add beep-based communications to the list of possible future needs. I don't see a problem here. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat Jul 7 23:13:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26600 for ; Sat, 7 Jul 2001 23:13:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20369; Sat, 7 Jul 2001 23:08:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20340 for ; Sat, 7 Jul 2001 23:08:44 -0400 (EDT) Received: from yourwebsite.com (cd-179-62.ra30.dc.capu.net [64.50.179.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26567 for ; Sat, 7 Jul 2001 23:07:56 -0400 (EDT) From: lprice@capu.net Message-Id: <200107080307.XAA26567@ietf.org> Reply-To: lprice@capu.net To: midcom@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 7 Jul 2001 23:04:32 -0400 Subject: [midcom] Ride the Wave of Success!!/FREE MEMBERSHIP!!! Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org JOIN NOW FOR FREE!!! SERIOUS ONLINE INCOME: NO PRODUCTS TO SELL, NO MEETING TO ATTEND, NO MONTHLY QUOTAS We are a FOUR 4 YEAR OLD INTERNET BUSINESS AND GROWING VERY FAST. WE HAD OVER 60,000 VIPS SIGNUP COMPANY WIDE IN THE MONTH OF JUNE 2001. SEE WHY THOUSANDS OF PEOPLE FROM ALL OVER THE WORLD ARE JOINING US AT RECORD RATES.; THE MEMBERSHIP IS FREE at. http://onlineprofits.50megs.com. . Enter your first and last name and email address. Afterwards you will start recieving various emails about company and the business opportunity. Also, you will become a FREE MEMBER and you can START SHOPPING from at least 70 brand name online stores and BE ENTERED in our monthly $100 shopping spree!. Take your time and review our company's benefits and opportunities. . GUARANTEED minimum commission every month . you can get 200 members a month added to you downline . Free Software . and a strong team support Now remember anybody that signs up after you will be in your downline. This is very important if you want join our company and get a monthly check. Don't pass this one up. GET YOUR FREE MEMBERSHIP AT: http://onlineprofits.50megs.com --- type in your name and email address and hit the submit botton. We will talk soon, GIVIE IT A TRY, YOU HAVE NOTHING TO LOSE AND POSSIBLE A LOT TO GAIN. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 9 13:39:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23344 for ; Mon, 9 Jul 2001 13:39:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03998; Mon, 9 Jul 2001 13:31:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03971 for ; Mon, 9 Jul 2001 13:31:31 -0400 (EDT) Received: from nemo.corp.equinix.com (somehost-3.equinix.net [207.20.85.155]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23001 for ; Mon, 9 Jul 2001 13:30:42 -0400 (EDT) From: hardie@equinix.com Received: (from hardie@localhost) by nemo.corp.equinix.com (8.9.3/8.9.3) id KAA27617; Mon, 9 Jul 2001 10:31:24 -0700 (PDT) Message-Id: <200107091731.KAA27617@nemo.corp.equinix.com> Subject: Re: [midcom] Firewall interaction with BEEP To: sbrim@cisco.com (Scott Brim) Date: Mon, 9 Jul 2001 10:31:24 -0700 (PDT) Cc: hardie@equinix.com, midcom@ietf.org In-Reply-To: <15174.29232.149000.544611@gargle.gargle.HOWL> from "Scott Brim" at Jul 06, 2001 10:21:36 PM Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Scott, Adding beep-based communications to the list of possible future needs would help, but I think we need more than a statement that the protocol syntax needs to be flexible. I think we need to explicitly say that the MIDCOM protocol must be able to handle control channels that fall into three categories: port based, mux-based, and external channel. For the midcom protocol to handle a port-based protocol (like WHOIS, for example) is pretty easy: the agent can request a pinhole for the specific port on a specific destination. For the external channel, the agent uses data from one channel to request a pinhole for a distinct src/dest pair. For a mux-based protocol, the agent must be able to do more, because the src/dest pair doesn't make for a full tuple; it must name the profiles as well. Without that, all beep profiles would have to be considered equivalent; the result would look much like a firewall control protocol that could only specific IP address (and could not specify port number): all tcp and udp-based protocols would look the same. Though I can't point to an existing firewall implementation to prove it, I have a strong suspicion that that won't suffice. regards, Ted Hardie > > On 6 Jul 2001 at 15:33 -0700, hardie@equinix.com apparently wrote: > > Despite there being no current firewall applications that are > > beep capable, I believe we may need language in the requirements > > document to cover the use of profiles within beep sessions. > > I think this comes down to a statement that the midcom protocol syntax > needs to be flexible enough to do not just what we are focused on right > now, but what others might need to do in the future -- we already have > this covered -- and that we should add beep-based communications to the > list of possible future needs. I don't see a problem here. > > ...Scott > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 9 14:27:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24898 for ; Mon, 9 Jul 2001 14:26:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05444; Mon, 9 Jul 2001 14:22:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05416 for ; Mon, 9 Jul 2001 14:22:53 -0400 (EDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24717 for ; Mon, 9 Jul 2001 14:22:02 -0400 (EDT) Received: from 157.54.9.100 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 09 Jul 2001 11:15:10 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 9 Jul 2001 11:15:07 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 9 Jul 2001 11:14:57 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 9 Jul 2001 11:14:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Firewall interaction with BEEP Date: Mon, 9 Jul 2001 11:14:04 -0700 Message-ID: Thread-Topic: [midcom] Firewall interaction with BEEP Thread-Index: AcEInUbsCQQivdpKRyi8F9NwyXTWfgABU8aQ From: "Christian Huitema" To: , "Scott Brim" Cc: X-OriginalArrivalTime: 09 Jul 2001 18:14:04.0571 (UTC) FILETIME=[EFE71EB0:01C108A2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA05417 Sender: 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 Ted, I don't think that it is a good idea to add additional requirements at this point in the game. We understand protocols and ports very well, and we should specify that. When firewalls get developed that perform specific treatment for BEEP, then we will study the extensions. By the way, BEEP is not unique there -- at some point we will also need extensions for SCTP, SOAP, and maybe even HTTP or SMTP... -- Christian Huitema > -----Original Message----- > From: hardie@equinix.com [mailto:hardie@equinix.com] > Sent: Monday, July 09, 2001 10:31 AM > To: Scott Brim > Cc: hardie@equinix.com; midcom@ietf.org > Subject: Re: [midcom] Firewall interaction with BEEP > > Scott, > Adding beep-based communications to the list of possible > future needs would help, but I think we need more than a statement > that the protocol syntax needs to be flexible. I think we need to > explicitly say that the MIDCOM protocol must be able to handle control > channels that fall into three categories: port based, mux-based, and > external channel. For the midcom protocol to handle a port-based > protocol (like WHOIS, for example) is pretty easy: the agent can > request a pinhole for the specific port on a specific destination. > For the external channel, the agent uses data from one channel to > request a pinhole for a distinct src/dest pair. For a mux-based > protocol, the agent must be able to do more, because the src/dest pair > doesn't make for a full tuple; it must name the profiles as well. > Without that, all beep profiles would have to be considered > equivalent; the result would look much like a firewall control > protocol > that could only specific IP address (and could not specify port > number): > all tcp and udp-based protocols would look the same. Though I > can't point to an existing firewall implementation to prove it, I > have a strong suspicion that that won't suffice. > regards, > Ted Hardie > > > > > > > > > > On 6 Jul 2001 at 15:33 -0700, hardie@equinix.com apparently wrote: > > > Despite there being no current firewall applications that are > > > beep capable, I believe we may need language in the requirements > > > document to cover the use of profiles within beep sessions. > > > > I think this comes down to a statement that the midcom protocol > syntax > > needs to be flexible enough to do not just what we are focused on > right > > now, but what others might need to do in the future -- we already > have > > this covered -- and that we should add beep-based communications to > the > > list of possible future needs. I don't see a problem here. > > > > ...Scott > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 9 14:33:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25244 for ; Mon, 9 Jul 2001 14:33:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05577; Mon, 9 Jul 2001 14:27:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05548 for ; Mon, 9 Jul 2001 14:27:11 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24883 for ; Mon, 9 Jul 2001 14:26:22 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA19584; Mon, 9 Jul 2001 14:27:00 -0400 (EDT) Message-Id: <200107091827.OAA19584@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: hardie@equinix.com cc: sbrim@cisco.com (Scott Brim), midcom@ietf.org Subject: Re: [midcom] Firewall interaction with BEEP In-reply-to: Your message of "Mon, 09 Jul 2001 10:31:24 PDT." <200107091731.KAA27617@nemo.corp.equinix.com> Date: Mon, 09 Jul 2001 14:27:00 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I think this is just further demonstration that we need for each protocol that the network is going to know about to have a unique port assignment, even if it's layered over a substrate such as BEEP. Expecting the network to sort out details of protocols higher than the packet level is not only a gross layering violation, it doesn't scale well. It's one thing to build firewalls that do this as a stopgap measure, but we shouldn't invest time trying to standardize such hacks. Keith > Scott, > Adding beep-based communications to the list of possible > future needs would help, but I think we need more than a statement > that the protocol syntax needs to be flexible. I think we need to > explicitly say that the MIDCOM protocol must be able to handle control > channels that fall into three categories: port based, mux-based, and > external channel. For the midcom protocol to handle a port-based > protocol (like WHOIS, for example) is pretty easy: the agent can > request a pinhole for the specific port on a specific destination. > For the external channel, the agent uses data from one channel to > request a pinhole for a distinct src/dest pair. For a mux-based > protocol, the agent must be able to do more, because the src/dest pair > doesn't make for a full tuple; it must name the profiles as well. > Without that, all beep profiles would have to be considered > equivalent; the result would look much like a firewall control protocol > that could only specific IP address (and could not specify port number): > all tcp and udp-based protocols would look the same. Though I > can't point to an existing firewall implementation to prove it, I > have a strong suspicion that that won't suffice. > regards, > Ted Hardie _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 9 15:16:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26263 for ; Mon, 9 Jul 2001 15:16:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06989; Mon, 9 Jul 2001 15:02:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAB06960 for ; Mon, 9 Jul 2001 15:02:27 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25967 for ; Mon, 9 Jul 2001 15:01:36 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f69J1uh05739; Mon, 9 Jul 2001 12:01:56 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-162.cisco.com [10.82.192.162]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AOG03352; Mon, 9 Jul 2001 12:01:48 -0700 (PDT) Message-Id: <5.1.0.14.0.20010709145534.00a18340@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 09 Jul 2001 15:02:53 -0400 To: "Christian Huitema" , , "Scott Brim" From: Melinda Shore Subject: RE: [midcom] Firewall interaction with BEEP Cc: 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 11:14 AM 7/9/01 -0700, Christian Huitema wrote: >I don't think that it is a good idea to add additional requirements at >this point in the game. We understand protocols and ports very well, and >we should specify that. I don't think that we should be requiring specifically BEEP profiles as demultiplexors, but it doesn't seem to me to be a huge stretch to require that the language be expressive enough to be able to transport stuff in addition to ports and addresses. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 9 16:30:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27976 for ; Mon, 9 Jul 2001 16:30:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09248; Mon, 9 Jul 2001 16:19:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09215 for ; Mon, 9 Jul 2001 16:18:59 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27738 for ; Mon, 9 Jul 2001 16:18:10 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id QAA20227; Mon, 9 Jul 2001 16:18:29 -0400 (EDT) Message-Id: <200107092018.QAA20227@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Melinda Shore cc: "Christian Huitema" , hardie@equinix.com, "Scott Brim" , midcom@ietf.org Subject: Re: [midcom] Firewall interaction with BEEP In-reply-to: Your message of "Mon, 09 Jul 2001 15:02:53 EDT." <5.1.0.14.0.20010709145534.00a18340@mira-sjc5-4.cisco.com> Date: Mon, 09 Jul 2001 16:18:29 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > I don't think that we should be requiring specifically > BEEP profiles as demultiplexors, but it doesn't seem to > me to be a huge stretch to require that the language be > expressive enough to be able to transport stuff in addition > to ports and addresses. to me this is a very huge stretch. why do we have layering at all if every network element is going to expect to look at arbitrary layers of the protocol stack? _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 9 16:49:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28215 for ; Mon, 9 Jul 2001 16:49:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10050; Mon, 9 Jul 2001 16:46:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10020 for ; Mon, 9 Jul 2001 16:46:08 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28136 for ; Mon, 9 Jul 2001 16:45:19 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f69KjgP28643; Mon, 9 Jul 2001 13:45:42 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-162.cisco.com [10.82.192.162]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AOI00720; Mon, 9 Jul 2001 13:44:52 -0700 (PDT) Message-Id: <5.1.0.14.0.20010709164021.00a19060@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 09 Jul 2001 16:45:28 -0400 To: Keith Moore From: Melinda Shore Subject: Re: [midcom] Firewall interaction with BEEP Cc: "Christian Huitema" , hardie@equinix.com, "Scott Brim" , midcom@ietf.org In-Reply-To: <200107092018.QAA20227@astro.cs.utk.edu> References: 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:18 PM 7/9/01 -0400, Keith Moore wrote >to me this is a very huge stretch. why do we have layering >at all if every network element is going to expect to look >at arbitrary layers of the protocol stack? If a firewall is going to to pass BEEP traffic it's going to be looking into the payload, anyway. This is a symptom, not the disease. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 9 16:53:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28310 for ; Mon, 9 Jul 2001 16:53:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10151; Mon, 9 Jul 2001 16:50:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10118 for ; Mon, 9 Jul 2001 16:50:19 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28207 for ; Mon, 9 Jul 2001 16:49:31 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id QAA20620; Mon, 9 Jul 2001 16:50:07 -0400 (EDT) Message-Id: <200107092050.QAA20620@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Melinda Shore cc: Keith Moore , "Christian Huitema" , hardie@equinix.com, "Scott Brim" , midcom@ietf.org Subject: Re: [midcom] Firewall interaction with BEEP In-reply-to: Your message of "Mon, 09 Jul 2001 16:45:28 EDT." <5.1.0.14.0.20010709164021.00a19060@mira-sjc5-4.cisco.com> Date: Mon, 09 Jul 2001 16:50:07 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > >to me this is a very huge stretch. why do we have layering > >at all if every network element is going to expect to look > >at arbitrary layers of the protocol stack? > > If a firewall is going to to pass BEEP traffic it's going to be > looking into the payload, anyway. This is a symptom, not the > disease. in that case, seems like the disease is trying to decide whether you can reasonably pass the traffic by looking at the content, rather than by looking at whether the parties are authorized to communicate. but my point is - we need to be working on scalable and technically sane approaches, not trying to standardize non-scalable hacks. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 9 17:02:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28459 for ; Mon, 9 Jul 2001 17:02:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10361; Mon, 9 Jul 2001 16:57:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10329 for ; Mon, 9 Jul 2001 16:57:39 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28381 for ; Mon, 9 Jul 2001 16:56:50 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f69KvCh07276; Mon, 9 Jul 2001 13:57:12 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (rtp-vpn2-4.cisco.com [10.82.96.4]) by airborne.cisco.com (Mirapoint) with ESMTP id AGE01871; Mon, 9 Jul 2001 13:56:52 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15178.6800.52000.350951@gargle.gargle.HOWL> Date: Mon, 9 Jul 2001 16:56:48 -0400 To: Melinda Shore Cc: Keith Moore , "Christian Huitema" , hardie@equinix.com, midcom@ietf.org Subject: Re: [midcom] Firewall interaction with BEEP In-Reply-To: <5.1.0.14.0.20010709164021.00a19060@mira-sjc5-4.cisco.com> References: <5.1.0.14.0.20010709164021.00a19060@mira-sjc5-4.cisco.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit On 9 Jul 2001 at 16:45 -0400, Melinda Shore apparently wrote: > At 04:18 PM 7/9/01 -0400, Keith Moore wrote > >to me this is a very huge stretch. why do we have layering > >at all if every network element is going to expect to look > >at arbitrary layers of the protocol stack? > > If a firewall is going to to pass BEEP traffic it's going to be > looking into the payload, anyway. This is a symptom, not the > disease. But it doesn't have to look at it with higher layer semantics (if it does we've just reproduced the current situation). I think we can do this. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 9 17:05:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28657 for ; Mon, 9 Jul 2001 17:05:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10794; Mon, 9 Jul 2001 17:01:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10766 for ; Mon, 9 Jul 2001 17:01:27 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28421 for ; Mon, 9 Jul 2001 17:00:38 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA20800; Mon, 9 Jul 2001 17:00:34 -0400 (EDT) Message-Id: <200107092100.RAA20800@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Scott Brim" cc: Melinda Shore , Keith Moore , "Christian Huitema" , hardie@equinix.com, midcom@ietf.org Subject: Re: [midcom] Firewall interaction with BEEP In-reply-to: Your message of "Mon, 09 Jul 2001 16:56:48 EDT." <15178.6800.52000.350951@gargle.gargle.HOWL> Date: Mon, 09 Jul 2001 17:00:34 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > > If a firewall is going to to pass BEEP traffic it's going to be > > looking into the payload, anyway. This is a symptom, not the > > disease. > > But it doesn't have to look at it with higher layer semantics (if it > does we've just reproduced the current situation). I think we can do > this. we shouldn't standardize looking below the packet layer. if people want the network to distinguish different kinds of traffic, they need to expose that distinction to the network - not expect the network to parse the traffic streams. anybody else remember when we understood why separation of function between layers was important? Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 9 17:31:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29070 for ; Mon, 9 Jul 2001 17:31:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11318; Mon, 9 Jul 2001 17:21:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11287 for ; Mon, 9 Jul 2001 17:21:20 -0400 (EDT) Received: from nemo.corp.equinix.com (somehost-3.equinix.net [207.20.85.155]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28951 for ; Mon, 9 Jul 2001 17:20:31 -0400 (EDT) From: hardie@equinix.com Received: (from hardie@localhost) by nemo.corp.equinix.com (8.9.3/8.9.3) id OAA05176; Mon, 9 Jul 2001 14:21:15 -0700 (PDT) Message-Id: <200107092121.OAA05176@nemo.corp.equinix.com> Subject: Re: [midcom] Firewall interaction with BEEP To: moore@cs.utk.edu (Keith Moore) Date: Mon, 9 Jul 2001 14:21:15 -0700 (PDT) Cc: hardie@equinix.com, sbrim@cisco.com (Scott Brim), midcom@ietf.org In-Reply-To: <200107091827.OAA19584@astro.cs.utk.edu> from "Keith Moore" at Jul 09, 2001 02:27:00 PM Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Keith, Given the threat model firewalls address, I find it very unlikely that assigning a port number to specific beep-substrate protocols would solve the problem. I believe it very likely that the firewalls will have to inspect at least the control channel of beep sessions to meet their security requirements. On the other hand, I expect that if a firewall sees something that is not allowed in such a session it will close the whole beep session, rather than trying to eliminate some channel in the mux. This isn't the worst case, but as you note, it isn't pretty. Unfortunately, I can't see how a firewall could meet its security requirements in the face of beep's characteristics without doing so. If you have another way of approaching the problem, now is the time to get it out, because we don't have any beep-capable firewalls to work around and we have a reasonable opportunity to suggest less problematic behavior. I raised this issue because this seems to be the time to ensure that the MIDCOM protocol syntax has sufficient flexibility to include information beyond host and port. There seem to me cases in which appropriate communication with firewalls does seem to require that the tuple for identification of permitted application goes beyond src,dest. Beep seems to me an important case in point. I agree with Christian that we understand src, dest well and do not understand all of the nuances of (src, dest, profiles), but I disagree that the work of getting that out should be put off. I strongly suspect that doing the work of understanding the needed semantics now will make getting an appropriate syntax correct far easier than working it out later as an addendum. After all, the base semantics for src,dest might need an "or" syntax at all, where the beep capable syntax needs to be able to handle something like "src and dest and (profile1 or profile2 or profile3)" or even "src and dest and not (profile1 or profile3)". regards, Ted Hardie Keith writes: > I think this is just further demonstration that we need for each > protocol that the network is going to know about to have a unique > port assignment, even if it's layered over a substrate such as BEEP. > Expecting the network to sort out details of protocols higher > than the packet level is not only a gross layering violation, > it doesn't scale well. It's one thing to build firewalls that > do this as a stopgap measure, but we shouldn't invest time trying > to standardize such hacks. > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 9 17:35:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29116 for ; Mon, 9 Jul 2001 17:35:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11809; Mon, 9 Jul 2001 17:31:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11778 for ; Mon, 9 Jul 2001 17:31:00 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29051 for ; Mon, 9 Jul 2001 17:30:11 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f69LUcx11495; Mon, 9 Jul 2001 14:30:38 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-162.cisco.com [10.82.192.162]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AOI02886; Mon, 9 Jul 2001 14:29:34 -0700 (PDT) Message-Id: <5.1.0.14.0.20010709172909.00a23e00@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 09 Jul 2001 17:30:39 -0400 To: Keith Moore , "Scott Brim" From: Melinda Shore Subject: Re: [midcom] Firewall interaction with BEEP Cc: Keith Moore , "Christian Huitema" , hardie@equinix.com, midcom@ietf.org In-Reply-To: <200107092100.RAA20800@astro.cs.utk.edu> References: 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 05:00 PM 7/9/01 -0400, Keith Moore wrote: >anybody else remember when we understood why separation of function >between layers was important? We're headed off-topic. Let's not. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 9 17:40:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29226 for ; Mon, 9 Jul 2001 17:40:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11957; Mon, 9 Jul 2001 17:36:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11929 for ; Mon, 9 Jul 2001 17:36:08 -0400 (EDT) Received: from nemo.corp.equinix.com (somehost-3.equinix.net [207.20.85.155]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29113 for ; Mon, 9 Jul 2001 17:35:19 -0400 (EDT) From: hardie@equinix.com Received: (from hardie@localhost) by nemo.corp.equinix.com (8.9.3/8.9.3) id OAA05678; Mon, 9 Jul 2001 14:36:02 -0700 (PDT) Message-Id: <200107092136.OAA05678@nemo.corp.equinix.com> Subject: Re: [midcom] Firewall interaction with BEEP To: moore@cs.utk.edu (Keith Moore) Date: Mon, 9 Jul 2001 14:36:02 -0700 (PDT) Cc: midcom@ietf.org, hardie@equinix.com (Ted Hardie) In-Reply-To: <200107092050.QAA20620@astro.cs.utk.edu> from "Keith Moore" at Jul 09, 2001 04:50:07 PM Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Keith, Sorry that I hadn't read this before I sent my previous response. The point I'm making is that parties may be authorized to carry out one communication type but not another. Given that beep allows you to multiplex different types of communication over a single session, someone attempting to decide whether to authorize the communication can do one of several things: 1) Authorize any communication which might use that session The consequence is that any beep-substrate protocol being allowed allows all beep-substrate protocols 2) Deny any communication which might use that session The consequence is that denying any beep-substrate protocol denies all beep-substrate protocols 3) Assign a different port to each beep-substrate protocol (a)If you trust the port assignment to eliminate beeps capability to multiplex different types of communication over the same session, you are back to src,dest (b)If you do not trust the port assignment, you are at (1) or (2), depending on whether you allow or deny. 4) Permit communication based on specific profiles (a)If you trust the profiles asserted the only ones which will use the assigned session, you open the pinhole and you're done. (b)If you don't trust that the profiles asserted are the only ones which one party might use during the session, you inspect the session and close it if a profile other than one asserted is used. Fundamentally, the issue of protocol layers comes down to this: beep does not use a classic port-assignment method of opening communication channels. It uses a profile negotiation method within a session. If we don't deal with that, we will not have restored the classic port-assignment method, we will simply have produced a middlebox communication protocol that is less useful than it might be. regards, Ted Hardie > > > >to me this is a very huge stretch. why do we have layering > > >at all if every network element is going to expect to look > > >at arbitrary layers of the protocol stack? > > > > If a firewall is going to to pass BEEP traffic it's going to be > > looking into the payload, anyway. This is a symptom, not the > > disease. > > in that case, seems like the disease is trying to decide whether you > can reasonably pass the traffic by looking at the content, rather than > by looking at whether the parties are authorized to communicate. > > but my point is - we need to be working on scalable and technically > sane approaches, not trying to standardize non-scalable hacks. > > Keith > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 9 17:43:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29298 for ; Mon, 9 Jul 2001 17:43:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12042; Mon, 9 Jul 2001 17:38:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12016 for ; Mon, 9 Jul 2001 17:38:28 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29177 for ; Mon, 9 Jul 2001 17:37:39 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA21036; Mon, 9 Jul 2001 17:38:18 -0400 (EDT) Message-Id: <200107092138.RAA21036@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: hardie@equinix.com cc: moore@cs.utk.edu (Keith Moore), sbrim@cisco.com (Scott Brim), midcom@ietf.org Subject: Re: [midcom] Firewall interaction with BEEP In-reply-to: Your message of "Mon, 09 Jul 2001 14:21:15 PDT." <200107092121.OAA05176@nemo.corp.equinix.com> Date: Mon, 09 Jul 2001 17:38:18 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > Given the threat model firewalls address, I find it very > unlikely that assigning a port number to specific beep-substrate > protocols would solve the problem. I believe it very likely that the > firewalls will have to inspect at least the control channel of beep > sessions to meet their security requirements. I have no doubt that firewalls that inspect content will continue to exist. The question is whether these should be explicitly supported with standard Internet protocols for controlling them. I think it is a terrible idea, because it encourages poor design and it doesn't scale. > This isn't the worst case, but as you note, it isn't pretty. > Unfortunately, I can't see how a firewall could meet its security > requirements in the face of beep's characteristics without doing so. > If you have another way of approaching the problem, now is the > time to get it out, because we don't have any beep-capable firewalls > to work around and we have a reasonable opportunity to suggest > less problematic behavior. I think midcom is inherently trying to solve a very limited problem, because as soon as you try to generalize it, it becomes intractable. So it needs to stick with the subset of the problem that is tractable. Yes, it's probably the case that whatever midcom produces will be only of limited utility. But I think that's a direct consequence of the solution space that midcom anticipates. > I raised this issue because this seems to be the time to > ensure that the MIDCOM protocol syntax has sufficient flexibility to > include information beyond host and port. There seem to me cases in > which appropriate communication with firewalls does seem to require > that the tuple for identification of permitted application goes beyond > src,dest. Beep seems to me an important case in point. I think it would be a very poor decision if we taught MIDCOM to deal with protocol information beyond host and port. MIDCOM should not try to support and encourage everything that firewalls do. That way lies madness. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 9 17:49:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29437 for ; Mon, 9 Jul 2001 17:49:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12207; Mon, 9 Jul 2001 17:43:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12180 for ; Mon, 9 Jul 2001 17:43:36 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29294 for ; Mon, 9 Jul 2001 17:42:47 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA21074; Mon, 9 Jul 2001 17:43:23 -0400 (EDT) Message-Id: <200107092143.RAA21074@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Melinda Shore cc: Keith Moore , "Scott Brim" , "Christian Huitema" , hardie@equinix.com, midcom@ietf.org Subject: Re: [midcom] Firewall interaction with BEEP In-reply-to: Your message of "Mon, 09 Jul 2001 17:30:39 EDT." <5.1.0.14.0.20010709172909.00a23e00@mira-sjc5-4.cisco.com> Date: Mon, 09 Jul 2001 17:43:23 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > We're headed off-topic. Let's not. if separation of layers is off topic, this entire group is off topic. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 9 17:51:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29475 for ; Mon, 9 Jul 2001 17:51:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12356; Mon, 9 Jul 2001 17:47:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12321 for ; Mon, 9 Jul 2001 17:47:20 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29377 for ; Mon, 9 Jul 2001 17:46:31 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f69Lkwx23002; Mon, 9 Jul 2001 14:46:58 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-162.cisco.com [10.82.192.162]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AOI03581; Mon, 9 Jul 2001 14:46:32 -0700 (PDT) Message-Id: <5.1.0.14.0.20010709174148.00a18750@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 09 Jul 2001 17:47:37 -0400 To: Keith Moore From: Melinda Shore Subject: Re: [midcom] Firewall interaction with BEEP Cc: midcom@ietf.org In-Reply-To: <200107092138.RAA21036@astro.cs.utk.edu> References: 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 05:38 PM 7/9/01 -0400, Keith Moore wrote: >I have no doubt that firewalls that inspect content will continue >to exist. The question is whether these should be explicitly >supported with standard Internet protocols for controlling them. >I think it is a terrible idea, because it encourages poor design >and it doesn't scale. Uh, Keith - what we're trying to do here is provide the infrastructure to allow firewalls to work without inspecting content. I think you have us confused with that other proposed working group, over there. Be that as it may, midcom is an existing working group with a specific charter and specific deliverables. If you expect us not to wander into the weeds that you happen not to like, please do not try to drag us into the weeds that you do like. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 9 17:54:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29541 for ; Mon, 9 Jul 2001 17:54:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12314; Mon, 9 Jul 2001 17:46:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12279 for ; Mon, 9 Jul 2001 17:46:51 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29363 for ; Mon, 9 Jul 2001 17:46:02 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA21094; Mon, 9 Jul 2001 17:46:50 -0400 (EDT) Message-Id: <200107092146.RAA21094@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: hardie@equinix.com cc: moore@cs.utk.edu (Keith Moore), midcom@ietf.org Subject: Re: [midcom] Firewall interaction with BEEP In-reply-to: Your message of "Mon, 09 Jul 2001 14:36:02 PDT." <200107092136.OAA05678@nemo.corp.equinix.com> Date: Mon, 09 Jul 2001 17:46:50 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > Sorry that I hadn't read this before I sent my previous response. The > point I'm making is that parties may be authorized to carry out one > communication type but not another. and my point is that the communication type needs to be exposed where firewalls can look at it. burying it inside beep just makes the firewall more complex, and doesn't do anything for security. beep shouldn't feel compelled to repeat the mistakes of those who want to layer arbitrary things over HTTP (or insert other misused protocol), and even if it does, midcom shouldn't feel compelled to encourage such mistakes. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 9 17:54:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29554 for ; Mon, 9 Jul 2001 17:54:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12450; Mon, 9 Jul 2001 17:50:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12417 for ; Mon, 9 Jul 2001 17:50:45 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29464 for ; Mon, 9 Jul 2001 17:49:56 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA21290; Mon, 9 Jul 2001 17:50:39 -0400 (EDT) Message-Id: <200107092150.RAA21290@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Melinda Shore cc: Keith Moore , midcom@ietf.org Subject: Re: [midcom] Firewall interaction with BEEP In-reply-to: Your message of "Mon, 09 Jul 2001 17:47:37 EDT." <5.1.0.14.0.20010709174148.00a18750@mira-sjc5-4.cisco.com> Date: Mon, 09 Jul 2001 17:50:39 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > >I have no doubt that firewalls that inspect content will continue > >to exist. The question is whether these should be explicitly > >supported with standard Internet protocols for controlling them. > >I think it is a terrible idea, because it encourages poor design > >and it doesn't scale. > > > Uh, Keith - what we're trying to do here is provide the infrastructure > to allow firewalls to work without inspecting content. I think you > have us confused with that other proposed working group, over there. Uh, Melinda - one way to read what I'm saying is that midcom should stay within its charter, in response to suggestions that it should deviate from its charter. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 9 21:12:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02887 for ; Mon, 9 Jul 2001 21:12:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17762; Mon, 9 Jul 2001 21:08:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17734 for ; Mon, 9 Jul 2001 21:08:52 -0400 (EDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02834 for ; Mon, 9 Jul 2001 21:08:03 -0400 (EDT) Received: from cisco.com (dhcp-2sjc13-85-244.cisco.com [171.70.85.244]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA16680; Mon, 9 Jul 2001 18:07:50 -0700 (PDT) Message-ID: <3B4A5572.405C17D1@cisco.com> Date: Mon, 09 Jul 2001 18:08:02 -0700 From: Eliot Lear Reply-To: lear@cisco.com X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hardie@equinix.com CC: Scott Brim , midcom@ietf.org Subject: Re: [midcom] Firewall interaction with BEEP References: <200107091731.KAA27617@nemo.corp.equinix.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 Ted, I'm sorry I didn't respond earlier to you, and so the following might seem like closing the barn door after the animals have left. I think we wandered into the woods when we started considering which applications are going to be availing themselves of network services, rather than focusing on those services themselves. BEEP may allow multiple applications to run in a single L4 data stream, but that doesn't mean it's a good idea. I would back up and give some guidance on just this point as it relates to firewalls. Otherwise we could easily re-invent the "everything over port 80" problem all over again. But while this idea was contemplated in the BEEP WG, is anyone actually doing this sort of thing? -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 9 21:32:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03174 for ; Mon, 9 Jul 2001 21:32:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18217; Mon, 9 Jul 2001 21:29:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA18155 for ; Mon, 9 Jul 2001 21:29:34 -0400 (EDT) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03102 for ; Mon, 9 Jul 2001 21:28:45 -0400 (EDT) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f6A1Ova29164; Mon, 9 Jul 2001 18:24:57 -0700 (PDT) Message-ID: <083b01c108df$c3914010$8753cf3f@FATORA> From: "Marshall T. Rose" To: , Cc: "Scott Brim" , , "Marshall Rose" References: <200107091731.KAA27617@nemo.corp.equinix.com> <3B4A5572.405C17D1@cisco.com> Subject: Re: [midcom] Firewall interaction with BEEP Date: Mon, 9 Jul 2001 18:29:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 > BEEP may allow > multiple applications to run in a single L4 data stream, but that doesn't > mean it's a good idea. > > I would back up and give some guidance on just this point as it relates to > firewalls. Otherwise we could easily re-invent the "everything over port > 80" problem all over again. But while this idea was contemplated in the > BEEP WG, is anyone actually doing this sort of thing? BEEP allows multiple channels to be running over a single L4 data stream, and those channels can be the same profile or different ones. the problem, i think, deals with terminology. in beep, an "application protocol" equals BEEP + 1 or more profiles + authorization policies + provisioning rules. provisioning rules deal with things like using SRV RRs or static port numbers or whatever. in addition to the "raison d'etre" profile, profiles can also include things like what you use to tune the session for the desired security properties. thus far, this thread doesn't seem to deal with this nuance, which is unfortunate, because it's an important one. if someone defines the "foo application protocol" as using BEEP, they are perfectly free to get a well-known port number for foo. so here's a simple question: does midcom care whether stuff on port 25 is actually smtp or not? if so, you have a larger problem than the dynamicism of beep. if not, whether an application protocol uses beep is a non-issue. /mtr _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 10 10:13:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29943 for ; Tue, 10 Jul 2001 10:13:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17788; Tue, 10 Jul 2001 10:06:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17759 for ; Tue, 10 Jul 2001 10:06:48 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29704 for ; Tue, 10 Jul 2001 10:05:54 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6ADUOx00702 for ; Tue, 10 Jul 2001 06:30:25 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-104.cisco.com [10.82.192.104]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AOL02562; Tue, 10 Jul 2001 06:30:14 -0700 (PDT) Message-Id: <5.1.0.14.0.20010710092000.009d17a0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Jul 2001 09:31:19 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Status update Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Just so everybody knows where we are ... The working group has two deliverables - a framework document and a requirements document. We are NOT responsible for delivering a protocol document. Both of the deliverables are supposed to be through working group last call and delivered to the IESG in August. I think we're on track for the framework document and somewhat behind schedule on the requirements document. The URLs for the documents are: http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-02.txt http://www.ietf.org/internet-drafts/draft-ietf-midcom-requirements-01.txt Please note that a revision of the framework document has been submitted to ietf-drafts and will be posted once it clears her queue. Please read it carefully once it's announced - if there is general agreement and no SUBSTANTIVE objections, it's the version that will go to last call. I expect several more iterations of the requirements document. We are tentatively scheduled to meet from 9am-11:30am on Thursday during the London IETF meeting. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 10 11:47:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04548 for ; Tue, 10 Jul 2001 11:47:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21391; Tue, 10 Jul 2001 11:40:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21358 for ; Tue, 10 Jul 2001 11:40:17 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04149 for ; Tue, 10 Jul 2001 11:39:26 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6AFc1429791; Tue, 10 Jul 2001 11:38:05 -0400 (EDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn2-8.cisco.com [10.21.112.8]) by airborne.cisco.com (Mirapoint) with ESMTP id AGF07799; Tue, 10 Jul 2001 08:39:22 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15179.8615.277000.406918@gargle.gargle.HOWL> Date: Tue, 10 Jul 2001 11:39:19 -0400 To: Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] Status update In-Reply-To: <5.1.0.14.0.20010710092000.009d17a0@mira-sjc5-4.cisco.com> References: <5.1.0.14.0.20010710092000.009d17a0@mira-sjc5-4.cisco.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I don't think we'll be able to get the Requirements draft ready for last call by the London meeting. It needs a major overhaul. I say this with regret. I want to be able to easily verify whether a particular protocol design meets the requirements. This document would help me if * I don't have to sift throug philosophy and context -- that's why we have a separate framework document. If we want context with our requirements we can combine the two drafts when we go to draft standard. Apart from actual requirements, the requirements document should just have scope and terminology (and these should be excerpted from the framework). * It lists all of the requirements succinctly, up front, e.g. in a table. It should also have justifications and notes, but in a separate major section. Right now the requirements are often interspersed with discussion text, and sometimes I can't tell what is supposed to be a requirement and what is not. * It is very clear about MUST, SHOULD, MAY etc. * The requirements should be distilled down to real operational requirements -- some of them are still somewhat abstract and what they refer to is not clearly defined. This is something we could have done on the mailing list but we've been busy. This would be much easier if the requirements were separated out from discussion text. Finally, I estimate that about 30% of the requirements listed would be contentious if we actually took the time to talk about them. What do I suggest? Sigh. I suggest we edit the current document with an axe. Take the existing text but totally reorganize it and remove the fat. Have: a (very!) brief introduction, scope, and terminology; then a succinct list of clear requirements that are not contentious at all; then a list of requirements which for which consensus has not been demonstrated; then finally, a completely separate section with discussion text for the different requirements (but only the text that is necessary for understanding the requirements). Optionally, for institutional memory, a major section of requirements that have been proposed but rejected, and why. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 10 14:33:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13758 for ; Tue, 10 Jul 2001 14:33:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27265; Tue, 10 Jul 2001 14:26:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27234 for ; Tue, 10 Jul 2001 14:25:58 -0400 (EDT) Received: from nemo.corp.equinix.com (somehost-3.equinix.net [207.20.85.155]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13296 for ; Tue, 10 Jul 2001 14:25:08 -0400 (EDT) From: hardie@equinix.com Received: (from hardie@localhost) by nemo.corp.equinix.com (8.9.3/8.9.3) id LAA14784; Tue, 10 Jul 2001 11:25:52 -0700 (PDT) Message-Id: <200107101825.LAA14784@nemo.corp.equinix.com> Subject: Re: [midcom] Firewall interaction with BEEP To: mrose+mtr.netnews@dbc.mtview.ca.us (Marshall T. Rose) Date: Tue, 10 Jul 2001 11:25:52 -0700 (PDT) Cc: lear@cisco.com, hardie@equinix.com, sbrim@cisco.com (Scott Brim), midcom@ietf.org In-Reply-To: <083b01c108df$c3914010$8753cf3f@FATORA> from "Marshall T. Rose" at Jul 09, 2001 06:29:28 PM Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit My sense is that some firewalls do care that the stuff on port 25 is actually smtp. I personally believe that that ability to name the application using a port would be useful in communications with firewalls that do care about such things. I also believe, however, that we don't have consensus in this working group on whether MIDCOM will require the ability to communicate to a firewall about what application/protocol is permitted on a specific port. Since we don't have consensus on that, the application of that ability to a multi-channel protocol like BEEP doesn't have a base to build on. The base requirement for MIDCOM in the firewall part of the fog is clearly to be able to request a pinhole by naming a src,dest pair. There seems to be some support for the ability to extend the MIDCOM semantics beyond src,dest to include other information. One extension might be to name the src, dest, and permitted profiles for beep sessions. Until that "some support" becomes consensus, though, I suggest that the requirements' doc include the weaker language Scott originally proposed, which supports flexibility but does not require explicit support of any particular extension. I don't want to take up working group time in London on this, but it might be useful for some of us with opinions on this to take advantage of some high-bandwidth hallway time to see if we can come to consensus on bringing this in or leaving it out. regards, Ted Hardie > > > BEEP may allow > > multiple applications to run in a single L4 data stream, but that doesn't > > mean it's a good idea. > > > > I would back up and give some guidance on just this point as it relates to > > firewalls. Otherwise we could easily re-invent the "everything over port > > 80" problem all over again. But while this idea was contemplated in the > > BEEP WG, is anyone actually doing this sort of thing? > > BEEP allows multiple channels to be running over a single L4 data stream, > and those channels can be the same profile or different ones. > > the problem, i think, deals with terminology. in beep, an "application > protocol" equals BEEP + 1 or more profiles + authorization policies + > provisioning rules. > > provisioning rules deal with things like using SRV RRs or static port > numbers or whatever. > > in addition to the "raison d'etre" profile, profiles can also include things > like what you use to tune the session for the desired security properties. > > thus far, this thread doesn't seem to deal with this nuance, which is > unfortunate, because it's an important one. > > if someone defines the "foo application protocol" as using BEEP, they are > perfectly free to get a well-known port number for foo. > > so here's a simple question: does midcom care whether stuff on port 25 is > actually smtp or not? > > if so, you have a larger problem than the dynamicism of beep. if not, > whether an application protocol uses beep is a non-issue. > > /mtr > > Eliot writes: > > BEEP may allow > > multiple applications to run in a single L4 data stream, but that doesn't > > mean it's a good idea. > > > > I would back up and give some guidance on just this point as it relates to > > firewalls. Otherwise we could easily re-invent the "everything over port > > 80" problem all over again. But while this idea was contemplated in the > > BEEP WG, is anyone actually doing this sort of thing? Marshall writes: > BEEP allows multiple channels to be running over a single L4 data stream, > and those channels can be the same profile or different ones. > > the problem, i think, deals with terminology. in beep, an "application > protocol" equals BEEP + 1 or more profiles + authorization policies + > provisioning rules. > > provisioning rules deal with things like using SRV RRs or static port > numbers or whatever. > > in addition to the "raison d'etre" profile, profiles can also include things > like what you use to tune the session for the desired security properties. > > thus far, this thread doesn't seem to deal with this nuance, which is > unfortunate, because it's an important one. > > if someone defines the "foo application protocol" as using BEEP, they are > perfectly free to get a well-known port number for foo. > > so here's a simple question: does midcom care whether stuff on port 25 is > actually smtp or not? > > if so, you have a larger problem than the dynamicism of beep. if not, > whether an application protocol uses beep is a non-issue. > > /mtr > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 10 15:34:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16794 for ; Tue, 10 Jul 2001 15:34:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29148; Tue, 10 Jul 2001 15:30:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29102 for ; Tue, 10 Jul 2001 15:30:10 -0400 (EDT) Received: from nemo.corp.equinix.com (somehost-3.equinix.net [207.20.85.155]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16597 for ; Tue, 10 Jul 2001 15:29:20 -0400 (EDT) From: hardie@equinix.com Received: (from hardie@localhost) by nemo.corp.equinix.com (8.9.3/8.9.3) id MAA17513; Tue, 10 Jul 2001 12:30:06 -0700 (PDT) Message-Id: <200107101930.MAA17513@nemo.corp.equinix.com> Subject: Re: [midcom] Firewall interaction with BEEP To: sbrim@cisco.com (Scott Brim) Date: Tue, 10 Jul 2001 12:30:06 -0700 (PDT) Cc: hardie@equinix.com, mrose+mtr.netnews@dbc.mtview.ca.us (Marshall T. Rose), lear@cisco.com, midcom@ietf.org In-Reply-To: <15179.19727.196000.887345@gargle.gargle.HOWL> from "Scott Brim" at Jul 10, 2001 02:44:31 PM Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Scott, I think the charter actually does pretty good job of putting this: Decomposing applications requiring policy decisions by removing application logic from the middle box and instead providing a generalized communications interface provides a number of benefits, including improved performance, lower software development and maintenance costs, improved ability to support traversal of packet filters by complex protocols, easier deployment of new applications, and the ability to consolidate management functions. For example, by moving stateful inspection of protocols such as H.323 and SIP out of firewalls, it is possible to improve performance and scalability and reduce development and costs. By raising this issue, I'm not trying to subvert the charter, sow confusion, or otherwise cause anyone's ulcer to grow. I am trying to point to an emerging protocol family based on a multi-channel architecture. APEX, IDXP, and other protocols are being developed in IETF contexts now using BEEP. Because they are multi-channel, they may admit of a less granular decomposition than other protocols; with a one-to-one mapping onto known ports, they may also look to a firewall exactly like protocols based directly on tcp. I have suggested using a bit of face time in London (outside the working group time) to discuss this further. A review of RFC 3080 and RFC 3081 for those interested would be useful. regards, Ted Hardie _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 10 15:54:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18802 for ; Tue, 10 Jul 2001 15:54:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29775; Tue, 10 Jul 2001 15:49:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29739 for ; Tue, 10 Jul 2001 15:49:11 -0400 (EDT) Received: from web14309.mail.yahoo.com (web14309.mail.yahoo.com [216.136.224.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18084 for ; Tue, 10 Jul 2001 15:48:20 -0400 (EDT) Message-ID: <20010710194907.62976.qmail@web14309.mail.yahoo.com> Received: from [207.164.4.47] by web14309.mail.yahoo.com via HTTP; Tue, 10 Jul 2001 15:49:07 EDT Date: Tue, 10 Jul 2001 15:49:07 -0400 (EDT) From: Abdallah Rayhan Subject: Re: [midcom] Firewall interaction with BEEP To: midcom@ietf.org Cc: midcom@ietf.org In-Reply-To: <083b01c108df$c3914010$8753cf3f@FATORA> 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 --- "Marshall T. Rose" wrote: > BEEP allows multiple channels to be running over a single L4 data > stream, > and those channels can be the same profile or different ones. > > the problem, i think, deals with terminology. in beep, an > "application > protocol" equals BEEP + 1 or more profiles + authorization policies + > provisioning rules. What do you call this? Application intelligence? Application awareness? Isn't that what we are trying to avoid? How does beep integrate currently with the framework? Can you say that a beep agent (in-path) would do the trick and isolate the awareness from the middlebox? Would OOP agent do it? Even if you use something like a profile to classify flows how can you escape NATing within the payload? Rather than re-inventing the framework to suit beep, can beep architecture been accommodated within the current framework? regards Abdallah _______________________________________________________ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 10 15:54:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18816 for ; Tue, 10 Jul 2001 15:54:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29736; Tue, 10 Jul 2001 15:49:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29704 for ; Tue, 10 Jul 2001 15:49:08 -0400 (EDT) Received: from web14309.mail.yahoo.com (web14309.mail.yahoo.com [216.136.224.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18082 for ; Tue, 10 Jul 2001 15:48:19 -0400 (EDT) Message-ID: <20010710194907.62976.qmail@web14309.mail.yahoo.com> Received: from [207.164.4.47] by web14309.mail.yahoo.com via HTTP; Tue, 10 Jul 2001 15:49:07 EDT Date: Tue, 10 Jul 2001 15:49:07 -0400 (EDT) From: Abdallah Rayhan Subject: Re: [midcom] Firewall interaction with BEEP To: midcom@ietf.org Cc: midcom@ietf.org In-Reply-To: <083b01c108df$c3914010$8753cf3f@FATORA> 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 --- "Marshall T. Rose" wrote: > BEEP allows multiple channels to be running over a single L4 data > stream, > and those channels can be the same profile or different ones. > > the problem, i think, deals with terminology. in beep, an > "application > protocol" equals BEEP + 1 or more profiles + authorization policies + > provisioning rules. What do you call this? Application intelligence? Application awareness? Isn't that what we are trying to avoid? How does beep integrate currently with the framework? Can you say that a beep agent (in-path) would do the trick and isolate the awareness from the middlebox? Would OOP agent do it? Even if you use something like a profile to classify flows how can you escape NATing within the payload? Rather than re-inventing the framework to suit beep, can beep architecture been accommodated within the current framework? regards Abdallah _______________________________________________________ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 10 16:04:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19828 for ; Tue, 10 Jul 2001 16:04:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00451; Tue, 10 Jul 2001 16:00:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00418 for ; Tue, 10 Jul 2001 16:00:52 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19431 for ; Tue, 10 Jul 2001 16:00:03 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6AIirl01993; Tue, 10 Jul 2001 11:44:53 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn2-8.cisco.com [10.21.112.8]) by airborne.cisco.com (Mirapoint) with ESMTP id AGF11362; Tue, 10 Jul 2001 11:44:35 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15179.19727.196000.887345@gargle.gargle.HOWL> Date: Tue, 10 Jul 2001 14:44:31 -0400 To: hardie@equinix.com Cc: mrose+mtr.netnews@dbc.mtview.ca.us (Marshall T. Rose), lear@cisco.com, midcom@ietf.org Subject: Re: [midcom] Firewall interaction with BEEP In-Reply-To: <200107101825.LAA14784@nemo.corp.equinix.com> References: <083b01c108df$c3914010$8753cf3f@FATORA> <200107101825.LAA14784@nemo.corp.equinix.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit On 10 Jul 2001 at 11:25 -0700, hardie@equinix.com apparently wrote: > I also believe, however, that we don't have consensus in this working > group on whether MIDCOM will require the ability to communicate to a > firewall about what application/protocol is permitted on a specific > port. My sense is that we have strong consensus that a middlebox shouldn't have to care, perhaps shouldn't be allowed to care, about the *meaning* of a particular port number, or anything else that implies anything about higher layer activity. We want middleboxes to be stupid. Educate your agents. > The base requirement for MIDCOM in the firewall part of the fog is > clearly to be able to request a pinhole by naming a src,dest pair. > There seems to be some support for the ability to extend the MIDCOM > semantics beyond src,dest to include other information. One extension > might be to name the src, dest, and permitted profiles for beep > sessions. I want to know, functionally, what you mean by "a profile". Is a profile represented by a particular byte value at a particular position in packets of a flow? How simple is it to find that value by looking at a packet as a string of bits and using downloadable rules? If it's easy then middleboxes can be dumb. If it's not I believe we should think about whether to support it in the midcom protocol. The midcom protocol has a chance of being lean and mean. If we have to make the protocol overweight just in order to support a case which might not even see widespread deployment, and which might be the only case requiring such complexity, then it might be better for everyone if you have your own specialized protocol. All those "mights" are why I want to know exactly what is required. What does it take to state a rule about a profile, when a middlebox knows nothing about your higher layer semantics? ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 10 16:18:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21232 for ; Tue, 10 Jul 2001 16:18:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00816; Tue, 10 Jul 2001 16:15:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00785 for ; Tue, 10 Jul 2001 16:15:10 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20945 for ; Tue, 10 Jul 2001 16:14:20 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6AKEml08143; Tue, 10 Jul 2001 13:14:48 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-104.cisco.com [10.82.192.104]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AOM06961; Tue, 10 Jul 2001 13:14:33 -0700 (PDT) Message-Id: <5.1.0.14.0.20010710160845.009e8b90@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Jul 2001 16:15:36 -0400 To: hardie@equinix.com From: Melinda Shore Subject: Re: [midcom] Firewall interaction with BEEP Cc: midcom@ietf.org In-Reply-To: <200107101825.LAA14784@nemo.corp.equinix.com> References: <083b01c108df$c3914010$8753cf3f@FATORA> 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:25 AM 7/10/01 -0700, hardie@equinix.com wrote: >The base requirement for MIDCOM in the firewall part of the fog is >clearly to be able to request a pinhole by naming a src,dest pair. >There seems to be some support for the ability to extend the MIDCOM >semantics beyond src,dest to include other information. One extension >might be to name the src, dest, and permitted profiles for beep >sessions. At this point we're really only talking about the protocol between an agent and a middlebox. We care about what the middlebox does to the extent that it shapes what we have to put in the protocol. Inasmuch as we're not specifying a protocol here, it seems to me that it's probably enough to put some text in the requirements document that the protocol language needs to be sufficiently expressive to be able to convey protocol and protocol demultiplexor information. In the meantime, as a point of information and NOT as a required part of the documents, if anybody has a firewall that already supports BEEP I'd personally be curious to know what they do. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 10 16:41:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22956 for ; Tue, 10 Jul 2001 16:41:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01603; Tue, 10 Jul 2001 16:36:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01572 for ; Tue, 10 Jul 2001 16:36:48 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22569 for ; Tue, 10 Jul 2001 16:35:58 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6AKaPl22763 for ; Tue, 10 Jul 2001 13:36:26 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-104.cisco.com [10.82.192.104]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AOM07796; Tue, 10 Jul 2001 13:35:54 -0700 (PDT) Message-Id: <5.1.0.14.0.20010710163609.00a21d90@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Jul 2001 16:36:54 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Meeting schedule update Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org We're now tentatively scheduled to meet on Wednesday, 8 August at 9am. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 10 18:00:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26424 for ; Tue, 10 Jul 2001 18:00:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03952; Tue, 10 Jul 2001 17:56:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03922 for ; Tue, 10 Jul 2001 17:56:57 -0400 (EDT) Received: from squid.squirehome.org (rdu163-42-132.nc.rr.com [24.163.42.132]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26296 for ; Tue, 10 Jul 2001 17:56:06 -0400 (EDT) Received: from acm.org (IDENT:msquire@squid.squirehome.org [192.168.168.2]) by squid.squirehome.org (8.11.0/8.11.0) with ESMTP id f6ALtXt01360; Tue, 10 Jul 2001 17:55:33 -0400 Message-ID: <3B4B79D5.BBC73518@acm.org> Date: Tue, 10 Jul 2001 17:55:33 -0400 From: Matt Squire Reply-To: mattsquire@acm.org X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en, pdf MIME-Version: 1.0 To: Scott Brim CC: hardie@equinix.com, "Marshall T. Rose" , lear@cisco.com, midcom@ietf.org Subject: Re: [midcom] Firewall interaction with BEEP References: <083b01c108df$c3914010$8753cf3f@FATORA> <200107101825.LAA14784@nemo.corp.equinix.com> <15179.19727.196000.887345@gargle.gargle.HOWL> 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 > We want middleboxes to be stupid. Educate > your agents. > At the risk of reinforcing the obvious: Yay, double yay, and a really big yay to go along with it. - Matt _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 10 19:06:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28878 for ; Tue, 10 Jul 2001 19:06:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06032; Tue, 10 Jul 2001 19:03:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06001 for ; Tue, 10 Jul 2001 19:03:35 -0400 (EDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28742 for ; Tue, 10 Jul 2001 19:02:46 -0400 (EDT) Received: from cisco.com (elear-dsl4.cisco.com [10.19.144.53]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA14981; Tue, 10 Jul 2001 16:02:28 -0700 (PDT) Message-ID: <3B4B6655.31394E1@cisco.com> Date: Tue, 10 Jul 2001 13:32:21 -0700 From: Eliot Lear Reply-To: lear@cisco.com X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Marshall T. Rose" CC: hardie@equinix.com, Scott Brim , midcom@ietf.org, Marshall Rose Subject: Re: [midcom] Firewall interaction with BEEP References: <200107091731.KAA27617@nemo.corp.equinix.com> <3B4A5572.405C17D1@cisco.com> <083b01c108df$c3914010$8753cf3f@FATORA> 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 Ultimately, Marshall, I think that the problem is not really BEEP's, but that of firewall vendors. Here is an example scenario which I think could happen: Some popular application, like the web, converts from HTTP to BEEP. Then someone builds a utility library for retrieval of pages based on URLs. That library in turn might call a process which does localized caching. So now you have multiple applications using the same code space, perhaps even going to the same locations. That's where things get interesting, especially if what we are talking about is a web cache. But as you say, all of this could virtually be done today, from a web cache, and the 5 tuple might not be enough to determine authorization. So that leaves open the question of "what is enough?" and how do you keep this from becoming a generalized query/response mechanism between the middlebox and the end host? Now there are perhaps some perverse things you could do with BEEP that would make Keith (and a whole lot of other good people) wretch all over their keyboards; like for instance, intercepting the BEEP connection and looking for particular profiles whose specific purpose is to communicate with midcom boxes. There are an infinite number of bad ideas out there. I cite this one simply for the purpose of demonstrating to friends a multicolored vegetable that used to be green. -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 10 20:58:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02055 for ; Tue, 10 Jul 2001 20:58:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08102; Tue, 10 Jul 2001 20:54:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08073 for ; Tue, 10 Jul 2001 20:54:45 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02011 for ; Tue, 10 Jul 2001 20:53:55 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id UAA29238; Tue, 10 Jul 2001 20:53:35 -0400 (EDT) Message-Id: <200107110053.UAA29238@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: hardie@equinix.com cc: mrose+mtr.netnews@dbc.mtview.ca.us (Marshall T. Rose), lear@cisco.com, sbrim@cisco.com (Scott Brim), midcom@ietf.org Subject: Re: [midcom] Firewall interaction with BEEP In-reply-to: Your message of "Tue, 10 Jul 2001 11:25:52 PDT." <200107101825.LAA14784@nemo.corp.equinix.com> Date: Tue, 10 Jul 2001 20:53:35 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > The base requirement for MIDCOM in the firewall part of the fog is > clearly to be able to request a pinhole by naming a src,dest pair. > There seems to be some support for the ability to extend the MIDCOM > semantics beyond src,dest to include other information. never mind that it's out of scope, or that it doesn't scale, or that it doesn't make good architectural sense. if there's "some support", we have to do it! I have a solution to this dilemma: Let every monkey have his own typewriter. Just don't expect IETF to endorse the results. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 10 21:09:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02242 for ; Tue, 10 Jul 2001 21:09:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA08547; Tue, 10 Jul 2001 21:06:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA08516 for ; Tue, 10 Jul 2001 21:06:25 -0400 (EDT) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02189 for ; Tue, 10 Jul 2001 21:05:35 -0400 (EDT) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f6B11ja03539; Tue, 10 Jul 2001 18:01:45 -0700 (PDT) Message-ID: <0efb01c109a5$b317cda0$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Scott Brim" Cc: , "Marshall Rose" References: <083b01c108df$c3914010$8753cf3f@FATORA><200107101825.LAA14784@nemo.corp.equinix.com> <15179.19727.196000.887345@gargle.gargle.HOWL> Subject: Re: [midcom] Firewall interaction with BEEP Date: Tue, 10 Jul 2001 18:05:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 want to know, functionally, what you mean by "a profile". Is a > profile represented by a particular byte value at a particular position > in packets of a flow? How simple is it to find that value by looking at > a packet as a string of bits and using downloadable rules? If it's easy > then middleboxes can be dumb. If it's not I believe we should think > about whether to support it in the midcom protocol. The midcom protocol > has a chance of being lean and mean. If we have to make the protocol > overweight just in order to support a case which might not even see > widespread deployment, and which might be the only case requiring such > complexity, then it might be better for everyone if you have your own > specialized protocol. in beep, "session", "profile" and "channel" are specific terms that have well-defined meanings. i'll answer all of your questions by using one example: MSG 0 1 . 52 120 Content-Type: application/beep+xml END this is a beep frame that contains a message on channel 0 asking to start a profile on channel 1. Accordingly: > Is a > profile represented by a particular byte value at a particular position > in packets of a flow? if you s/profile represented/channel for a profile started/, then the answer is "no". first, the frame header ("MSG ...") is variable-length; second, the payload for channel 0 is xml-based, so it too is variable-length, whitespace-friendly, etc. > How simple is it to find that value by looking at > a packet as a string of bits and using downloadable rules? if the "downloadable rules" can make use of a beep packet and xml interpreter, i'm sure it's trivial (insert a lot maniacal laughter here..) so, what does this tell us? to me, it says to stick with filtering on the basis of tcp header information (ip addrs, portnos) and not to deal with the data conveyed by tcp. that will certainly work for the things being developed by the ietf that use beep (e.g., the reliable syslog spec requests a well-known port number). /mtr _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 10 22:52:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06362 for ; Tue, 10 Jul 2001 22:52:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10642; Tue, 10 Jul 2001 22:43:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10613 for ; Tue, 10 Jul 2001 22:43:45 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06171 for ; Tue, 10 Jul 2001 22:42:55 -0400 (EDT) Received: from 157.54.9.101 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 10 Jul 2001 19:29:44 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 10 Jul 2001 19:28:44 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 10 Jul 2001 19:28:53 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 10 Jul 2001 19:27:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Firewall interaction with BEEP Date: Tue, 10 Jul 2001 19:27:58 -0700 Message-ID: Thread-Topic: [midcom] Firewall interaction with BEEP Thread-Index: AcEJpapgE9/prP/uS0SIGafKdXM3TwAC3oeA From: "Christian Huitema" To: "Marshall T. Rose" , "Scott Brim" Cc: , "Marshall Rose" X-OriginalArrivalTime: 11 Jul 2001 02:27:58.0668 (UTC) FILETIME=[199D38C0:01C109B1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA10614 Sender: 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 > > > > END > > this is a beep frame that contains a message on channel 0 asking to > start a > profile on channel 1. Whatever happened to "multiple layers of multiplexing considered harmful" ? _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jul 11 00:41:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09072 for ; Wed, 11 Jul 2001 00:41:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA13213; Wed, 11 Jul 2001 00:37:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA13181 for ; Wed, 11 Jul 2001 00:37:15 -0400 (EDT) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09001 for ; Wed, 11 Jul 2001 00:36:25 -0400 (EDT) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f6B4WXa03967; Tue, 10 Jul 2001 21:32:33 -0700 (PDT) Message-ID: <0f7d01c109c3$262312b0$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Christian Huitema" , "Scott Brim" Cc: , "Marshall Rose" References: Subject: Re: [midcom] Firewall interaction with BEEP Date: Tue, 10 Jul 2001 21:37:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 > Whatever happened to "multiple layers of multiplexing considered > harmful" ? gee, i don't know. it got discussed ad nauseum on the bxxp working group mailing list about a year ago. every time it comes up on another mailing list, i redirect the traffic to bxxpwg@invisible.net. /mtr ps: oh, the answer is: if you're careful, it can be okay. or, if you prefer the lear corollary: just make sure that people use well-debugged beep libraries instead of trying to roll their own beep subroutines... _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jul 11 07: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 SMTP id HAA00434 for ; Wed, 11 Jul 2001 07:33:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA01567; Wed, 11 Jul 2001 07:29:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA01502 for ; Wed, 11 Jul 2001 07:29:18 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00379 for ; Wed, 11 Jul 2001 07:28:27 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f6BBSkw27900 for ; Wed, 11 Jul 2001 12:28:46 +0100 (BST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Wed, 11 Jul 2001 12:28:27 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <3HB69D6Z>; Wed, 11 Jul 2001 12:28:22 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C304450AE@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'Melinda Shore'" , midcom@ietf.org, "Suresh (E-mail)" Subject: RE: [midcom] London meeting time Date: Wed, 11 Jul 2001 12:28:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C109FC.9683E780" Sender: 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_01C109FC.9683E780 Content-Type: text/plain; charset="iso-8859-1" I would really want us to discuss during the session how the extensibility of the Midcom protocol could be achieved to take into account other Middle Box functions. I'm sure that some of us (WG members) are looking for that. I don't think that people want to see another WG being created to take into account other Middlebox functions. The only problem is that how can we talk about the tools to achieve the extensibility if we didn't even finish the protocol requirements and started look at what existing protocol (with some extensions) Midcom should be. The extensibility could be achieved by a package (Megaco, MGCP way) or policy objects like with RSVP; I think we need to dig a little bit on this. There is another thing that we discussed briefly on the mailing list (emails between Andrew and Melinda) but didn't seem to move further: What is our definition of connection setup between the Midcom Agent and the Middlebox? Does it include any functions parameters negotiation? or do we rely on the registration phase to provide the proper settings and error notification messages (no I don't support that parameter or you're not allowed to asked that) will be used. The last method seems simpler and probably best to use. Cedric -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Friday, July 06, 2001 5:42 PM To: midcom@ietf.org Subject: [midcom] London meeting time We're tentatively scheduled to meet from 9-1130 on Thursday, 9 August. Also scheduled at that time are: APP trade Internet Open Trading Protocol WG OPS rap-II Resource Allocation Protocol WG SEC sacred Securely Available Credentials WG SUB-IP tewg Internet Traffic Engineering WG TSV avt-II Audio/Video Transport WG At the top of the agenda are wrapping up those things which need to be wrapped in the framework document and the requirements document. Please let me know if there's anything you feel *must* be addressed in the meeting beyond work on the documents. Note, however, that it would be very, very, very much appreciated if issues could be raised on the mailing list ahead of time - the meeting is not *the* place where work is done, but one place among several. The bulk of the work is done on mailing lists, and that's where consensus is developed. Also, as we prepare to go into last call on the framework document, do raise issues as soon as you become aware of them rather than waiting until the last minute and gumming up the process. Many thanks. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C109FC.9683E780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] London meeting time

I would really want us to discuss during the session = how the extensibility of the Midcom protocol
could be achieved to take into account other Middle = Box functions. I'm sure that some of us (WG members) are
looking for that. I don't think that people want to = see another WG being created to take into account other Middlebox = functions.

The only problem is that how can we talk about the = tools to achieve the extensibility
if we didn't even finish the protocol requirements = and started look at what existing protocol (with some extensions) = Midcom should be.

The extensibility could be achieved by a package = (Megaco, MGCP way) or policy objects like with RSVP; I think we need to = dig a little bit

on this.

There is another thing that we discussed briefly on = the mailing list (emails between Andrew and Melinda) but didn't seem to = move further:

What is our definition of connection setup between = the Midcom Agent and the Middlebox?
Does it include any functions parameters = negotiation? or do we rely on the registration phase to provide the = proper settings and error

notification messages (no I don't support that = parameter or you're not allowed to asked that) will be used.
The last method seems simpler and probably best to = use.
Cedric




-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Friday, July 06, 2001 5:42 PM
To: midcom@ietf.org
Subject: [midcom] London meeting time


We're tentatively scheduled to meet from 9-1130 on = Thursday, 9
August.  Also scheduled at that time = are:
APP     trade   =         Internet Open Trading = Protocol WG
OPS     rap-II  =         Resource Allocation Protocol = WG
SEC     sacred  =         Securely Available = Credentials WG
SUB-IP  tewg    =         Internet Traffic Engineering = WG
TSV     avt-II  =         Audio/Video Transport = WG

At the top of the agenda are wrapping up those things = which need
to be wrapped in the framework document and the = requirements
document.  Please let me know if there's = anything you feel *must*
be addressed in the meeting beyond work on the = documents.

Note, however, that it would be very, very, very much = appreciated
if issues could be raised on the mailing list ahead = of time - the
meeting is not *the* place where work is done, but = one place
among several.  The bulk of the work is done on = mailing lists, and
that's where consensus is developed.

Also, as we prepare to go into last call on the = framework document,
do raise issues as soon as you become aware of them = rather than
waiting until the last minute and gumming up the = process.  Many
thanks.

Melinda


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

------_=_NextPart_001_01C109FC.9683E780-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jul 11 09:18:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02605 for ; Wed, 11 Jul 2001 09:18:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04083; Wed, 11 Jul 2001 09:11:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04054 for ; Wed, 11 Jul 2001 09:11:31 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02340 for ; Wed, 11 Jul 2001 09:10:40 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6BDAql09875; Wed, 11 Jul 2001 06:10:52 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn1-32.cisco.com [10.21.96.32]) by airborne.cisco.com (Mirapoint) with ESMTP id AGF22537; Wed, 11 Jul 2001 06:10:47 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15180.20565.637000.851618@gargle.gargle.HOWL> Date: Wed, 11 Jul 2001 09:10:45 -0400 To: "Marshall T. Rose" Cc: , "Marshall Rose" Subject: Re: [midcom] Firewall interaction with BEEP In-Reply-To: <0efb01c109a5$b317cda0$8753cf3f@FATORA> References: <083b01c108df$c3914010$8753cf3f@FATORA> <200107101825.LAA14784@nemo.corp.equinix.com> <15179.19727.196000.887345@gargle.gargle.HOWL> <0efb01c109a5$b317cda0$8753cf3f@FATORA> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit On 10 Jul 2001 at 18:05 -0700, Marshall T. Rose apparently wrote: > if the "downloadable rules" can make use of a beep packet and xml > interpreter, i'm sure it's trivial (insert a lot maniacal laughter here..) I actually did laugh. > to me, it says to stick with filtering on the basis of tcp header > information (ip addrs, portnos) and not to deal with the data conveyed by > tcp. > > that will certainly work for the things being developed by the ietf that use > beep (e.g., the reliable syslog spec requests a well-known port number). Right. Beep is clearly so far up the stack that filtering out different profiles, or even channels, shouldn't be a concern of the network. I think hosts are going to have to take care of their own security at that level. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jul 11 10:28:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05126 for ; Wed, 11 Jul 2001 10:28:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06412; Wed, 11 Jul 2001 10:24:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06378 for ; Wed, 11 Jul 2001 10:24:12 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04738; Wed, 11 Jul 2001 10:23:21 -0400 (EDT) Message-Id: <200107111423.KAA04738@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 11 Jul 2001 10:23:21 -0400 Subject: [midcom] I-D ACTION:draft-sijben-rtp-proxy-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTP proxies for firewall traversal Author(s) : M. de Boer et al. Filename : draft-sijben-rtp-proxy-00.txt Pages : 23 Date : 10-Jul-01 This draft describes how a MEGACO controlled RTP proxy can be used to provide firewall traversal for media flows for SIP calls. The MEGACO profile described in this draft can be used to support any UDP flow. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sijben-rtp-proxy-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-sijben-rtp-proxy-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-sijben-rtp-proxy-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010710154021.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-sijben-rtp-proxy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-sijben-rtp-proxy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010710154021.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jul 11 10: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 SMTP id KAA05124 for ; Wed, 11 Jul 2001 10:28:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06534; Wed, 11 Jul 2001 10:24:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06505 for ; Wed, 11 Jul 2001 10:24:42 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04838; Wed, 11 Jul 2001 10:23:51 -0400 (EDT) Message-Id: <200107111423.KAA04838@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: Wed, 11 Jul 2001 10:23:51 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-framework-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 Communication Architecture and framework Author(s) : P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan Filename : draft-ietf-midcom-framework-03.txt Pages : 35 Date : 10-Jul-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-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-framework-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-framework-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: <20010710154110.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-framework-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-framework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010710154110.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jul 11 10:50:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06023 for ; Wed, 11 Jul 2001 10:50:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07363; Wed, 11 Jul 2001 10:46:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07332 for ; Wed, 11 Jul 2001 10:46:18 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05907 for ; Wed, 11 Jul 2001 10:45:26 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6BEjgl18058; Wed, 11 Jul 2001 07:45:42 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn1-32.cisco.com [10.21.96.32]) by airborne.cisco.com (Mirapoint) with ESMTP id AGF23234; Wed, 11 Jul 2001 07:45:39 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.92 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15180.26257.51000.859454@gargle.gargle.HOWL> Date: Wed, 11 Jul 2001 10:45:37 -0400 To: "Cedric Aoun" Cc: "'Melinda Shore'" , midcom@ietf.org, "Suresh (E-mail)" Subject: RE: [midcom] London meeting time In-Reply-To: <9154CB41F208D5118DD200508BE39C304450AE@zjguc006.europe.nortel.com> References: <9154CB41F208D5118DD200508BE39C304450AE@zjguc006.europe.nortel.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit On 11 Jul 2001 at 12:28 +0100, Cedric Aoun apparently wrote: > I would really want us to discuss during the session how the extensibility > of the Midcom protocol > could be achieved to take into account other Middle Box functions. I'm sure > that some of us (WG members) are > looking for that. I don't think that people want to see another WG being > created to take into account other Middlebox functions. Cedric, first of all, this mailing list is the main session. The physical meetings are (imo) mainly to work out details which we fail to work out in mail. Bring up issues here. Type a lot. > The only problem is that how can we talk about the tools to achieve the > extensibility > if we didn't even finish the protocol requirements and started look at what > existing protocol (with some extensions) Midcom should be. Right. We really need to look at real life requirements. How extensible does this protocol actually need to be? How much will each level of extensibility cost us in terms of robustness, security, etc.? > The extensibility could be achieved by a package (Megaco, MGCP way) or > policy objects like with RSVP; I think we need to dig a little bit > on this. I understand the objects/elements approach. I don't know what you mean by using a "package". > There is another thing that we discussed briefly on the mailing list (emails > between Andrew and Melinda) but didn't seem to move further: > What is our definition of connection setup between the Midcom Agent and the > Middlebox? How does this sound for a summary (inspired by Christian, Suresh and others)? The relationship between agent and middlebox should be stateless. "Setup" consists merely of authentication & authorization of the middlebox, and version/parameter negotiations (as you mention) such as establishment of how transactions will be signed, possible encryption, etc. There is no further state necessary or wanted. In order to make this possible, all transactions should be in absolute terms (e.g. absolute expiration times for pinholes). No particular agent should "own" a pinhole or any other installed rule -- if an agent is authorized to manipulate a rule then that agent can do so. Agent authorization should be as specific as necessary to support this. Conflicts and confusion between battling agents should not be resolved by complex state in the middlebox and notifications, but rather by interactions between the agents themselves. This keeps the middlebox clean. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jul 11 18:09:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22386 for ; Wed, 11 Jul 2001 18:09:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18420; Wed, 11 Jul 2001 18:02:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18383 for ; Wed, 11 Jul 2001 18:01:39 -0400 (EDT) Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22116 for ; Wed, 11 Jul 2001 18:00:45 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f6BM17w01729 for ; Wed, 11 Jul 2001 23:01:07 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Wed, 11 Jul 2001 23:00:53 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <32MBBR9J>; Wed, 11 Jul 2001 23:00:52 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C304450BC@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'Scott Brim'" Cc: "'Melinda Shore'" , midcom@ietf.org, "Suresh (E-mail)" Subject: RE: [midcom] London meeting time Date: Wed, 11 Jul 2001 23:00:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10A54.F4C4E6C0" Sender: 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_01C10A54.F4C4E6C0 Content-Type: text/plain; charset="iso-8859-1" On 11 Jul 2001 at 12:28 +0100, Cedric Aoun apparently wrote: > I would really want us to discuss during the session how the extensibility > of the Midcom protocol > could be achieved to take into account other Middle Box functions. I'm sure > that some of us (WG members) are > looking for that. I don't think that people want to see another WG being > created to take into account other Middlebox functions. Cedric, first of all, this mailing list is the main session. The physical meetings are (imo) mainly to work out details which we fail to work out in mail. Bring up issues here. Type a lot. CA>Scott, I was mentioning that as part of the potential discussions for our session in London. I was preferring that we discuss the extensibility after 51 on the list. This is MAINLY to maintain the focus on delivery of our 2 documents on time. I completely agree with you, more than 95% should be done in the list since we have 7.5 h per year where we discuss face to face. > The only problem is that how can we talk about the tools to achieve the > extensibility > if we didn't even finish the protocol requirements and started look at what > existing protocol (with some extensions) Midcom should be. Right. We really need to look at real life requirements. How extensible does this protocol actually need to be? How much will each level of extensibility cost us in terms of robustness, security, etc.? CA>What I meant by extensibility is how can we make MIDCOM request other functions from the Middle Box? Currently we only thought about Qos as being one of other functions that the Middle Box could handle. Packet diversion for legal intercept reasons might be another one (but I didn't hear anybody mentioning that one). How can we add these functions without major changes in the Midcom protocol? That's why I mentioned usage of packages or policy objects to do that. > The extensibility could be achieved by a package (Megaco, MGCP way) or > policy objects like with RSVP; I think we need to dig a little bit > on this. I understand the objects/elements approach. I don't know what you mean by using a "package". CA>Apologies for the confuse that this brought, a package is also an object it has a descriptor and properties for each parameter of the descriptor. I used the term package due to a potential usage of device control protocols such as Megaco to be the Midcom protocol. > There is another thing that we discussed briefly on the mailing list (emails > between Andrew and Melinda) but didn't seem to move further: > What is our definition of connection setup between the Midcom Agent and the > Middlebox? How does this sound for a summary (inspired by Christian, Suresh and others)? The relationship between agent and middlebox should be stateless. "Setup" consists merely of authentication & authorization of the middlebox, and version/parameter negotiations (as you mention) such as establishment of how transactions will be signed, possible encryption, etc. There is no further state necessary or wanted. In order to make this possible, all transactions should be in absolute terms (e.g. absolute expiration times for pinholes). No particular agent should "own" a pinhole or any other installed rule -- if an agent is authorized to manipulate a rule then that agent can do so. Agent authorization should be as specific as necessary to support this. Conflicts and confusion between battling agents should not be resolved by complex state in the middlebox and notifications, but rather by interactions between the agents themselves. This keeps the middlebox clean. CA>This sounds reasonable, but I don't think I have seen it that way in the fmwrk or the protocol reqs documents. Cedric ...Scott ------_=_NextPart_001_01C10A54.F4C4E6C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] London meeting time

On 11 Jul 2001 at 12:28 +0100, Cedric Aoun apparently = wrote:
> I would really want us to discuss during the = session how the extensibility
> of the Midcom protocol
> could be achieved to take into account other = Middle Box functions. I'm sure
> that some of us (WG members) are
> looking for that. I don't think that people = want to see another WG being
> created to take into account other Middlebox = functions.

Cedric, first of all, this mailing list is the main = session.  The
physical meetings are (imo) mainly to work out = details which we fail to
work out in mail.  Bring up issues here.  = Type a lot.


CA>Scott, I was mentioning that as part of the = potential discussions for our
session in London. I was preferring that we discuss = the extensibility
after 51 on the list. This is MAINLY to maintain the = focus on delivery of
our 2 documents on time.
I completely agree with you, more than 95% should be = done in the list since we
have 7.5 h per year where we discuss face to = face.

> The only problem is that how can we talk about = the tools to achieve the
> extensibility
> if we didn't even finish the protocol = requirements and started look at what
> existing protocol (with some extensions) Midcom = should be.

Right.  We really need to look at real life = requirements.  How
extensible does this protocol actually need to = be?  How much will each
level of extensibility cost us in terms of = robustness, security, etc.?

CA>What I meant by extensibility is how can we = make MIDCOM request other
functions from the Middle Box?
Currently we only thought about Qos as being one of = other functions that the Middle Box
could handle. Packet diversion for legal intercept = reasons might be another one (but I didn't hear
anybody mentioning that one).
How can we add these functions without major changes = in the Midcom protocol?
That's why I mentioned usage of packages or policy = objects to do that.


> The extensibility could be achieved by a package = (Megaco, MGCP way) or
> policy objects like with RSVP; I think we need = to dig a little bit
> on this.

I understand the objects/elements approach.  I = don't know what you mean
by using a "package".

CA>Apologies for the confuse that this brought, a = package is also an object it has a descriptor and properties for each =

parameter of the descriptor.
I used the term package due to a potential usage of = device control protocols such as Megaco to be the Midcom = protocol.



> There is another thing that we discussed briefly = on the mailing list (emails
> between Andrew and Melinda) but didn't seem to = move further:
> What is our definition of connection setup = between the Midcom Agent and the
> Middlebox?

How does this sound for a summary (inspired by = Christian, Suresh and
others)?  The relationship between agent and = middlebox should be
stateless.  "Setup" consists merely = of authentication & authorization of
the middlebox, and version/parameter negotiations = (as you mention) such
as establishment of how transactions will be signed, = possible
encryption, etc.  There is no further state = necessary or wanted.  In
order to make this possible, all transactions should = be in absolute
terms (e.g. absolute expiration times for = pinholes).  No particular
agent should "own" a pinhole or any other = installed rule -- if an agent
is authorized to manipulate a rule then that agent = can do so.  Agent
authorization should be as specific as necessary to = support this.
Conflicts and confusion between battling agents = should not be resolved
by complex state in the middlebox and notifications, = but rather by
interactions between the agents themselves.  = This keeps the middlebox
clean.

CA>This sounds reasonable, but I don't think I = have seen it that way in the fmwrk or
the protocol reqs documents.
Cedric

...Scott

------_=_NextPart_001_01C10A54.F4C4E6C0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jul 11 19:34:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24795 for ; Wed, 11 Jul 2001 19:34:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20053; Wed, 11 Jul 2001 19:25:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20026 for ; Wed, 11 Jul 2001 19:24:58 -0400 (EDT) Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24559 for ; Wed, 11 Jul 2001 19:24:08 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id B42A28198; Wed, 11 Jul 2001 18:21:51 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id SAA29179; Wed, 11 Jul 2001 18:21:51 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Wed, 11 Jul 2001 18:21:51 -0500 (CDT) From: Andrew Molitor To: Scott Brim Cc: Cedric Aoun , "'Melinda Shore'" , midcom@ietf.org, "Suresh (E-mail)" Subject: RE: [midcom] London meeting time In-Reply-To: <15180.26257.51000.859454@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Wed, 11 Jul 2001, Scott Brim wrote: > How does this sound for a summary (inspired by Christian, Suresh and > others)? The relationship between agent and middlebox should be > stateless. "Setup" consists merely of authentication & authorization of > the middlebox, and version/parameter negotiations (as you mention) such > as establishment of how transactions will be signed, possible > encryption, etc. There is no further state necessary or wanted. In > order to make this possible, all transactions should be in absolute > terms (e.g. absolute expiration times for pinholes). No particular > agent should "own" a pinhole or any other installed rule -- if an agent > is authorized to manipulate a rule then that agent can do so. Agent > authorization should be as specific as necessary to support this. > Conflicts and confusion between battling agents should not be resolved > by complex state in the middlebox and notifications, but rather by > interactions between the agents themselves. This keeps the middlebox > clean. This is pretty good, with a couple of caveats and remarks: Obviously some type of agent<->middlebox connection state should be maintained, (transaction sequence number, or a TCP stream, or something) to make the authentication work properly without handshaking or something on every transaction. I assume I'm just being pedantic, and that this is understood? I don't follow why statelessness and non-ownership-of-stuff implies Absolute timer values? I don't see how 'expire this pinhole 10 minutes from now' is different from 'expire this pinhole at ' are sunstantively different, since they can be trivially converted into one another (with suitable caveats for clock differences -- which by the by delta times will work MUCH better in the face of). Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jul 11 21:20:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26582 for ; Wed, 11 Jul 2001 21:20:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22238; Wed, 11 Jul 2001 21:16:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22207 for ; Wed, 11 Jul 2001 21:16:32 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26431 for ; Wed, 11 Jul 2001 21:15:41 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6C0tIQ23875; Wed, 11 Jul 2001 18:13:16 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn1-87.cisco.com [10.21.96.87]) by airborne.cisco.com (Mirapoint) with ESMTP id AGG06369; Wed, 11 Jul 2001 17:50:14 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.94 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15180.62532.990000.763376@gargle.gargle.HOWL> Date: Wed, 11 Jul 2001 20:50:12 -0400 To: Andrew Molitor Cc: midcom@ietf.org Subject: RE: [midcom] London meeting time In-Reply-To: References: <15180.26257.51000.859454@gargle.gargle.HOWL> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit On 11 Jul 2001 at 18:21 -0500, Andrew Molitor apparently wrote: > Obviously some type of agent<->middlebox connection state should > be maintained, (transaction sequence number, or a TCP stream, or > something) to make the authentication work properly without handshaking > or something on every transaction. I assume I'm just being pedantic, > and that this is understood? Sequence numbers (at the midcom level, not TCP) will probably help with security. I hope we won't want to use TCP. What are the requirements? > I don't follow why statelessness and non-ownership-of-stuff > implies Absolute timer values? I don't see how 'expire this pinhole > 10 minutes from now' is different from 'expire this pinhole > at ' are sunstantively different, > since they can be trivially converted into one another (with suitable > caveats for clock differences -- which by the by delta times will > work MUCH better in the face of). The absolute timer came out of concerns about replays. It was Eric or Melinda or both who suggested that if you only allowed messages with absolute timers about when an event should occur that replays would be less of an issue so your security could be lighter-weight. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jul 11 21:39:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27727 for ; Wed, 11 Jul 2001 21:39:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22641; Wed, 11 Jul 2001 21:30:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22606 for ; Wed, 11 Jul 2001 21:30:55 -0400 (EDT) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26708 for ; Wed, 11 Jul 2001 21:30:04 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 2682C814F for ; Wed, 11 Jul 2001 19:38:13 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id UAA05370 for ; Wed, 11 Jul 2001 20:30:55 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Wed, 11 Jul 2001 20:30:54 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] London meeting time In-Reply-To: <15180.62532.990000.763376@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Wed, 11 Jul 2001, Scott Brim wrote: > On 11 Jul 2001 at 18:21 -0500, Andrew Molitor apparently wrote: > Sequence numbers (at the midcom level, not TCP) will probably help with > security. I hope we won't want to use TCP. What are the requirements? My personal feelings are that UDP is the way to go, since TCP's backoff behavior is just not what you want in a real-time environment. In a UDP-like environment, the only way I know how to do client (Agent) authentication is to use sequence numbered connection-stateful sort of arrangement, which a server (middlebox) supplied cookie or initial sequence number or similar in each packet. This allows your digital signatures to be robust against replay attacks (at least by clients against the server -- it's not symmetrical -- to the devil with the client's needs ;) The only option I am aware of is to do a multi-packet exchange for each message exchange: - client sends a 'hi, can I talk to you?' - server replies 'sure, your signature looks good, have a cookie' - client says 'here is transaction, and thanks for the cookie' - server says 'ACK' Obviously if you maintain a little connection state, namely the cookie, at each end, you can repeat the steps 3 and 4 as often as you like. In TCP-land, you can essentially use the TCP state itself as a kind of internal cookie, which works pretty well as long as your TCP stack doesn't reuse initial sequence numbers very often or predictably. Um, I think. I'm no crypto expert, so take all of the above with a good sized grain of salt. > > I don't follow why statelessness and non-ownership-of-stuff > > implies Absolute timer values? I don't see how 'expire this pinhole > > 10 minutes from now' is different from 'expire this pinhole > > at ' are sunstantively different, > > since they can be trivially converted into one another (with suitable > > caveats for clock differences -- which by the by delta times will > > work MUCH better in the face of). > > The absolute timer came out of concerns about replays. It was Eric or > Melinda or both who suggested that if you only allowed messages with > absolute timers about when an event should occur that replays would be > less of an issue so your security could be lighter-weight. That's not a bad idea. If I was some kind of layering purity nazi, I'd point out that you are mixing up security considerations in the minutia of the rest of your protocol. Heck, if I was me I'd point it out, and since I am me.. I think it's not a bad idea, but it's not a very good one either -- solve the general problem of security properly, and let the protocol semantics do the Right thing, and keep them separate. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 12 09:32:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20121 for ; Thu, 12 Jul 2001 09:32:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16283; Thu, 12 Jul 2001 09:31:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16234 for ; Thu, 12 Jul 2001 09:31:30 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19915 for ; Thu, 12 Jul 2001 09:30:42 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6CDVAZ00314; Thu, 12 Jul 2001 06:31:10 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp248.cisco.com [10.21.64.248]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AOS10438; Thu, 12 Jul 2001 06:30:43 -0700 (PDT) Message-Id: <5.1.0.14.0.20010712092707.00a29560@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 12 Jul 2001 09:31:51 -0400 To: Andrew Molitor , midcom@ietf.org From: Melinda Shore Subject: RE: [midcom] London meeting time In-Reply-To: References: <15180.62532.990000.763376@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 08:30 PM 7/11/01 -0500, Andrew Molitor wrote: > My personal feelings are that UDP is the way to go, since >TCP's backoff behavior is just not what you want in a real-time >environment. I believe that all IETF protocols are now expected to employ TCP-compatible congestion response mechanisms. That's not an argument against using UDP, but it is something to be aware of. > That's not a bad idea. If I was some kind of layering purity >nazi, I'd point out that you are mixing up security considerations in >the minutia of the rest of your protocol. Heck, if I was me I'd point >it out, and since I am me.. I think it's not a bad idea, but it's >not a very good one either -- solve the general problem of security >properly, and let the protocol semantics do the Right thing, and >keep them separate. I don't agree that it is a layering violation (unless your layers are more finely-grained than is usual when talking about IP), but even so, do note that putting some sort of nonce into the payload does the same thing *and* requires maintaining longitudinal state. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 12 12:05:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11779 for ; Thu, 12 Jul 2001 12:05:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20998; Thu, 12 Jul 2001 12:03:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20970 for ; Thu, 12 Jul 2001 12:03:56 -0400 (EDT) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11437 for ; Thu, 12 Jul 2001 12:03:07 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 3C818814B for ; Thu, 12 Jul 2001 10:05:09 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id KAA04534 for ; Thu, 12 Jul 2001 10:58:09 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Thu, 12 Jul 2001 10:58:09 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] London meeting time In-Reply-To: <5.1.0.14.0.20010712092707.00a29560@mira-sjc5-4.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Thu, 12 Jul 2001, Melinda Shore wrote: > At 08:30 PM 7/11/01 -0500, Andrew Molitor wrote: > > My personal feelings are that UDP is the way to go, since > >TCP's backoff behavior is just not what you want in a real-time > >environment. > > I believe that all IETF protocols are now expected to employ > TCP-compatible congestion response mechanisms. That's not an > argument against using UDP, but it is something to be aware of. If I put on my standard hat, I arrive pretty quickly at the 'should run over UDP or TCP' exactly for these reasons. Obviously a TCP implementation would do that vis a vis congestion, and a UDP implementation would let you play games. This seems to be pretty common, and I'd be surprised if we DON'T get there. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 12 13:06:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20576 for ; Thu, 12 Jul 2001 13:06:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22422; Thu, 12 Jul 2001 13:00:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22380 for ; Thu, 12 Jul 2001 13:00:07 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19624 for ; Thu, 12 Jul 2001 12:59:18 -0400 (EDT) Received: from 157.54.9.101 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 12 Jul 2001 09:40:30 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 12 Jul 2001 09:40:29 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 12 Jul 2001 09:40:11 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 12 Jul 2001 09:39:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] London meeting time Date: Thu, 12 Jul 2001 09:39:32 -0700 Message-ID: Thread-Topic: [midcom] London meeting time Thread-Index: AcEK7HCvA3WeHI8CTqSfOsCKVg13hwAAwMPA From: "Christian Huitema" To: "Andrew Molitor" , X-OriginalArrivalTime: 12 Jul 2001 16:39:33.0314 (UTC) FILETIME=[3ACF3A20:01C10AF1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA22381 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > On Thu, 12 Jul 2001, Melinda Shore wrote: > > > At 08:30 PM 7/11/01 -0500, Andrew Molitor wrote: > > > My personal feelings are that UDP is the way to go, since > > >TCP's backoff behavior is just not what you want in a real-time > > >environment. > > > > I believe that all IETF protocols are now expected to employ > > TCP-compatible congestion response mechanisms. That's not an > > argument against using UDP, but it is something to be aware of. > > If I put on my standard hat, I arrive pretty quickly at > the 'should run over UDP or TCP' exactly for these reasons. Obviously > a TCP implementation would do that vis a vis congestion, and > a UDP implementation would let you play games. This seems to be > pretty common, and I'd be surprised if we DON'T get there. The classic "sweet spot" of UDP is the handling of multiple short transactions with a large number of parties -- by and large the traffic profile of the DNS. Using TCP in such applications is counter-productive, since you have to wrap a simple exchange between a three way handshake and a final disconnect -- there is extra traffic, and there is basically no congestion control gain, since the TCP connections are too short to move out of slow start. I am not sure that Midcom fits under that profile. In fact, we have a performance requirement that was outlined in the list discussion, and that I would summarize as follow: The SIP and H.323 scenarios mention the control of the midcom server by a single midcom agent collocated with a SIP proxy or an H.323 gatekeeper. In these situations, we may expect a heavy amount of traffic between the midcom agent and the midcom server, and it is important to design the protocol in a way that supports high performance. The typical impediments to high performance are high transaction cost and windowing effect. A large fraction of the transaction cost will derive from the security requirements, which will result in a conjunction of cryptographic applications and database look-up, e.g. using Radius; both encryption and look-up can be slow and costly. A specific requirement is to distinguish between the operations that are common to many transactions, such as the authentication of the midcom server to the midcom agent and the midcom agent to the midcom server, and the actions that are specific to a single transaction. The windowing effects occur when a specific transaction has to wait for the completion of a previous transaction. From a performance point of view, it may be acceptable to wait for the confirmation of the opening of a pin-hole before closing the same pin-hole. (This may not be acceptable from a security point of view.) But it would not be acceptable to wait for the completion of one pin-hole opening before allowing the opening of another pin-hole. In summary, the following must be true: * It should be possible to exchange authentication information once, and use the result for a series of transactions between a client and a midcom server, * It should be possible for a client to send multiple transactions without waiting for the results of previous transactions. I believe that this text provides a better "requirement" than merely stating "run over UDP" versus "run over TCP". In particular, the performance requirement combined with the security requirement may well lead us towards an "authenticated session" model, e.g. running over TLS. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 12 14:32:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01749 for ; Thu, 12 Jul 2001 14:32:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24653; Thu, 12 Jul 2001 14:29:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24624 for ; Thu, 12 Jul 2001 14:29:26 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01229 for ; Thu, 12 Jul 2001 14:28:37 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6CISeb24577 for ; Thu, 12 Jul 2001 14:28:40 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Thu, 12 Jul 2001 14:28:40 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <3HJ2Z0MC>; Thu, 12 Jul 2001 14:28:42 -0400 Message-ID: From: "Fernando Cuervo" To: "'Christian Huitema'" , Andrew Molitor , midcom Subject: RE: [midcom] London meeting time Date: Thu, 12 Jul 2001 14:28:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10B00.789300D0" 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_01C10B00.789300D0 Content-Type: text/plain; charset="iso-8859-1" There are two separate issues around the choice of transport: 1-security implications: If TCP and UDP are to be allowed then a security element in the protocol or use IPSec are needed 2-transaction capabilities: given that the issue is reliability the use of UDP requires that timers and retransmissions to be handled by the protocol. However, regardless of TCP or UDP things such as transaction in progress or even an abort command (to handle the open/close pin-hole scenario) may be useful, therefore it would be wise to leave all transaction control to the protocol, which is compatible with the dual use of TCP and UDP. > -----Original Message----- > From: Christian Huitema [SMTP:huitema@windows.microsoft.com] > Sent: Thursday, July 12, 2001 12:40 PM > To: Andrew Molitor; midcom > Subject: RE: [midcom] London meeting time > > > > On Thu, 12 Jul 2001, Melinda Shore wrote: > > > > > At 08:30 PM 7/11/01 -0500, Andrew Molitor wrote: > > > > My personal feelings are that UDP is the way to go, since > > > >TCP's backoff behavior is just not what you want in a real-time > > > >environment. > > > > > > I believe that all IETF protocols are now expected to employ > > > TCP-compatible congestion response mechanisms. That's not an > > > argument against using UDP, but it is something to be aware of. > > > > If I put on my standard hat, I arrive pretty quickly at > > the 'should run over UDP or TCP' exactly for these reasons. Obviously > > a TCP implementation would do that vis a vis congestion, and > > a UDP implementation would let you play games. This seems to be > > pretty common, and I'd be surprised if we DON'T get there. > > The classic "sweet spot" of UDP is the handling of multiple short > transactions with a large number of parties -- by and large the traffic > profile of the DNS. Using TCP in such applications is > counter-productive, since you have to wrap a simple exchange between a > three way handshake and a final disconnect -- there is extra traffic, > and there is basically no congestion control gain, since the TCP > connections are too short to move out of slow start. > > I am not sure that Midcom fits under that profile. In fact, we have a > performance requirement that was outlined in the list discussion, and > that I would summarize as follow: > > The SIP and H.323 scenarios mention the control of the > midcom server by a single midcom agent collocated with a SIP > proxy > or an H.323 gatekeeper. In these situations, we may > expect a heavy amount of traffic between the midcom agent and > the > midcom server, and it is important to design the protocol in a > way > that supports high performance. The typical impediments to high > performance are high transaction cost and windowing effect. > > A large fraction of the transaction cost will derive from the > security requirements, which will result in a conjunction of > cryptographic applications and database look-up, e.g. using > Radius; both encryption and look-up can be slow and costly. A > specific requirement is to distinguish between the operations > that > are common to many transactions, such as the authentication of > the > midcom server to the midcom agent and the midcom agent to the > midcom server, and the actions that are specific to a single > transaction. > > The windowing effects occur when a specific transaction has to > wait for the completion of a previous transaction. From a > performance point of view, it may be acceptable to wait for the > confirmation of the opening of a pin-hole before closing the > same > pin-hole. (This may not be acceptable from a security point of > view.) But it would not be acceptable to wait for the completion > of one pin-hole opening before allowing the opening of another > pin-hole. > > In summary, the following must be true: > > * It should be possible to exchange authentication > information > once, and use the result for a series of transactions > between a client and a midcom server, > > * It should be possible for a client to send multiple > transactions without waiting for the results of previous > transactions. > > I believe that this text provides a better "requirement" than merely > stating "run over UDP" versus "run over TCP". In particular, the > performance requirement combined with the security requirement may well > lead us towards an "authenticated session" model, e.g. running over TLS. > > -- Christian Huitema > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C10B00.789300D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] London meeting time

There are two = separate issues around the choice of transport:
1-security = implications: If TCP and UDP are to be allowed then a security element = in the protocol or use IPSec are needed

2-transaction = capabilities: given that the issue is reliability the use of UDP = requires that timers and retransmissions to be handled by the protocol. = However, regardless of TCP or UDP things such as transaction in = progress or even an abort command (to handle the open/close pin-hole = scenario) may be useful, therefore it would be wise to leave all = transaction control to the protocol, which is compatible with the dual = use of TCP and UDP.

    -----Original Message-----
    From:   Christian Huitema = [SMTP:huitema@windows.microsoft.com]
    Sent:   Thursday, July 12, 2001 12:40 PM
    To:     Andrew Molitor; midcom
    Subject:       = RE: [midcom] London meeting = time


    > On Thu, 12 Jul 2001, Melinda = Shore wrote:
    >
    > > At 08:30 PM 7/11/01 -0500, = Andrew Molitor wrote:
    > > = >        My personal feelings are = that UDP is the way to go, since
    > > >TCP's backoff behavior = is just not what you want in a real-time
    > > >environment.
    > >
    > > I believe that all IETF = protocols are now expected to employ
    > > TCP-compatible congestion = response mechanisms.  That's not an
    > > argument against using UDP, = but it is something to be aware of.
    >
    >       = If I put on my standard hat, I arrive pretty quickly at
    > the 'should run over UDP or TCP' = exactly for these reasons. Obviously
    > a TCP implementation would do = that vis a vis congestion, and
    > a UDP implementation would let = you play games. This seems to be
    > pretty common, and I'd be = surprised if we DON'T get there.

    The classic "sweet spot" of = UDP is the handling of multiple short
    transactions with a large number of = parties -- by and large the traffic
    profile of the DNS. Using TCP in such = applications is
    counter-productive, since you have to = wrap a simple exchange between a
    three way handshake and a final = disconnect -- there is extra traffic,
    and there is basically no congestion = control gain, since the TCP
    connections are too short to move out = of slow start.

    I am not sure that Midcom fits under = that profile. In fact, we have a
    performance requirement that was = outlined in the list discussion, and
    that I would summarize as = follow:

            The SIP and H.323 scenarios mention the control of the =
            midcom server by a single midcom agent collocated with a = SIP
    proxy
            or an H.323 gatekeeper. In these situations, we = may
            expect a heavy amount of traffic between the midcom = agent and
    the
            midcom server, and it is important to design the = protocol in a
    way
            that supports high performance. The typical impediments = to high
            performance are high transaction cost and windowing = effect.

            A large fraction of the transaction cost will derive = from the
            security requirements, which will result in a = conjunction of
            cryptographic applications and database look-up, e.g. = using
            Radius; both encryption and look-up can be slow and = costly. A
            specific requirement is to distinguish between the = operations
    that
            are common to many transactions, such as the = authentication of
    the
            midcom server to the midcom agent and the midcom agent = to the
            midcom server, and the actions that are specific to a = single
            transaction.

            The windowing effects occur when a specific transaction = has to
            wait for the completion of a previous transaction. From = a
            performance point of view, it may be acceptable to wait = for the
            confirmation of the opening of a pin-hole before closing = the
    same
            pin-hole. (This may not be acceptable from a security = point of
            view.) But it would not be acceptable to wait for the = completion
    of one pin-hole opening before = allowing the opening of another
            pin-hole.

            In summary, = the following must be true:

            *       It should be = possible to exchange authentication
    information
            =         once, and use the result for a series of transactions =
            =         between a client and a midcom server,

            *       It should be = possible for a client to send multiple
            =         transactions without waiting for the results of = previous
            =         transactions.

    I believe that this text provides a = better "requirement" than merely
    stating "run over UDP" = versus "run over TCP". In particular, the
    performance requirement combined with = the security requirement may well
    lead us towards an = "authenticated session" model, e.g. running over TLS.

    -- Christian Huitema

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

------_=_NextPart_001_01C10B00.789300D0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 12 14:51:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05659 for ; Thu, 12 Jul 2001 14:51:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25364; Thu, 12 Jul 2001 14:51:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25335 for ; Thu, 12 Jul 2001 14:51:01 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05127 for ; Thu, 12 Jul 2001 14:50:11 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6CIoZP07581; Thu, 12 Jul 2001 11:50:35 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp248.cisco.com [10.21.64.248]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AOS21429; Thu, 12 Jul 2001 11:50:27 -0700 (PDT) Message-Id: <5.1.0.14.0.20010712145037.00a0b580@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 12 Jul 2001 14:51:32 -0400 To: "Fernando Cuervo" , "'Christian Huitema'" , Andrew Molitor , midcom From: Melinda Shore Subject: RE: [midcom] London meeting time In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 02:28 PM 7/12/01 -0400, Fernando Cuervo wrote: >There are two separate issues around the choice of transport: >1-security implications: If TCP and UDP are to be allowed then a security element in the protocol or use IPSec are needed > >2-transaction capabilities: given that the issue is reliability the use of UDP requires that timers and retransmissions to be handled by the protocol. However, regardless of TCP or UDP things such as transaction in progress or even an abort command (to handle the open/close pin-hole scenario) may be useful, therefore it would be wise to leave all transaction control to the protocol, which is compatible with the dual use of TCP and UDP. Not to be tiresome, but we are not choosing a transport. We need to describe the characteristics we require of the transport. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 12 16:23:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18631 for ; Thu, 12 Jul 2001 16:23:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27539; Thu, 12 Jul 2001 16:15:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27512 for ; Thu, 12 Jul 2001 16:15:48 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17549 for ; Thu, 12 Jul 2001 16:15:00 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA27155 for ; Thu, 12 Jul 2001 13:14:32 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id NAA13937 for ; Thu, 12 Jul 2001 13:15:48 -0700 (PDT) Received: from xch-pssbh-01.nw.nos.boeing.com by blv-hub-01.boeing.com with ESMTP; Thu, 12 Jul 2001 13:15:40 -0700 Received: by xch-pssbh-01.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id <3B4BZH4G>; Thu, 12 Jul 2001 13:15:40 -0700 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12E50@XCH-NW-01.nw.nos.boeing.com> From: "Fleischman, Eric W" To: "'Fernando Cuervo'" , "'Christian Huitema'" , Andrew Molitor , midcom Subject: RE: [midcom] London meeting time Date: Thu, 12 Jul 2001 13:15:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org It isn't clear to me what a "transaction" means to the Midcom WG. My own use of the term is directly influenced by application layer concerns and explicitly includes two phased commits (e.g., for databases and transactional systems). But some may use the term in the sense of "agreement instance between the midcom agent and the middlebox". Which meaning is being used here? Specifically, are we proposing that two-phased commit semantics be used for Midcom? If so, why? -----Original Message----- From: Fernando Cuervo [mailto:cuervo@nortelnetworks.com] Sent: Thursday, July 12, 2001 11:29 AM To: 'Christian Huitema'; Andrew Molitor; midcom Subject: RE: [midcom] London meeting time There are two separate issues around the choice of transport: 1-security implications: If TCP and UDP are to be allowed then a security element in the protocol or use IPSec are needed 2-transaction capabilities: given that the issue is reliability the use of UDP requires that timers and retransmissions to be handled by the protocol. However, regardless of TCP or UDP things such as transaction in progress or even an abort command (to handle the open/close pin-hole scenario) may be useful, therefore it would be wise to leave all transaction control to the protocol, which is compatible with the dual use of TCP and UDP. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 12 17:28:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27158 for ; Thu, 12 Jul 2001 17:28:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28958; Thu, 12 Jul 2001 17:27:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28927 for ; Thu, 12 Jul 2001 17:27:39 -0400 (EDT) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26908 for ; Thu, 12 Jul 2001 17:26:50 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 4F624816B for ; Thu, 12 Jul 2001 15:34:34 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id QAA22248 for ; Thu, 12 Jul 2001 16:27:41 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Thu, 12 Jul 2001 16:27:41 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] London meeting time In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Thu, 12 Jul 2001, Christian Huitema wrote: > In summary, the following must be true: > > * It should be possible to exchange authentication > information > once, and use the result for a series of transactions > between a client and a midcom server, > > * It should be possible for a client to send multiple > transactions without waiting for the results of previous > transactions. > > I believe that this text provides a better "requirement" than merely > stating "run over UDP" versus "run over TCP". In particular, the > performance requirement combined with the security requirement may well > lead us towards an "authenticated session" model, e.g. running over TLS. I am in violent agreement with you. On or around Mar 28 I wrote: ----------------------- * - must support low-latency, high-throughput operation, with * best effort to maintain low latency in the face of a lossy network. * This is necessary for telecom grade operations -- backoff * policies in retransmit timers are not necessarily a good idea * on controlled channels controlling equipment. (This boils * down to: TCP Considered Harmful -- in rather specific * environments.) * * - must also support more ordinary network traffic models for * use on standard networks where backoff policies for retransmit * timers, and the like, are a good ideas. (This boils down to: * TCP is a hell of a good idea most of the time.) * * [ I think the first bullet above pretty much requires UDP * transport with wicked timers, but if there's anothe option * I'd be pleased to hear about it. The situation I am thinking * of is: some goober in a POP unplugs the wrong cable for * a moment, or there is some other glitch in connectivity. * It would Be Bad if this glitch made TCP back off and make * the POP unable to complete calls for, say, 2 or 3 seconds * AFTER connectivity is restored. This could readily create * irritating post-dial delays for several hundred customers * over the next 10 seconds while the queue clears. This is the * sort of thing that gives telecom geeks nightmares. ] - should be transport independent, a la SIP. - must support high transaction throughput over highish latency networks (read: must support message streaming.) ------------------- I then spent far more effort than it was worth explaining why this is a) a requirement and b) why one cannot safely assume that "it's a transport problem" and not take at least a little care in the protocol itself. Now I can at least imagine it was not all in vain ;) Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jul 13 18:24:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20895 for ; Fri, 13 Jul 2001 18:24:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09037; Fri, 13 Jul 2001 18:08:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09008 for ; Fri, 13 Jul 2001 18:08:46 -0400 (EDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18883 for ; Fri, 13 Jul 2001 18:07:55 -0400 (EDT) Received: from cisco.com (dhcp-2sjc13-85-244.cisco.com [171.70.85.244]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA01946; Fri, 13 Jul 2001 15:08:13 -0700 (PDT) Message-ID: <3B4F715C.E53A80B4@cisco.com> Date: Fri, 13 Jul 2001 15:08:28 -0700 From: Eliot Lear Reply-To: lear@cisco.com X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Molitor CC: midcom@ietf.org Subject: Re: [midcom] London meeting time References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit We've gotten into protocol selection/design. Perhaps this discussion is a bit early, but anyway... As anyone who followed the RSIP discussion knows, I have a very strong bias AGAINST having an implementation be both TCP AND UDP. There are two and a half closely related reasons for this: 1. It's more code to write and maintain 2. Any lesser used code path is a potential security hazard, and certainly a haven for bugs. 2.5 One of our touted reasons for success over other alternatives has been our LACK of options. Since the question is really what form should state remain, I am inclined to suggest that we decide which we need to guard more carefully- latency or the resources on the middlebox, while not trading off security, pick one and run with it. Let's not have another protocol that is both a floor wax AND a dessert topping. Eliot Lear Andrew Molitor wrote: > > On Thu, 12 Jul 2001, Melinda Shore wrote: > > > At 08:30 PM 7/11/01 -0500, Andrew Molitor wrote: > > > My personal feelings are that UDP is the way to go, since > > >TCP's backoff behavior is just not what you want in a real-time > > >environment. > > > > I believe that all IETF protocols are now expected to employ > > TCP-compatible congestion response mechanisms. That's not an > > argument against using UDP, but it is something to be aware of. > > If I put on my standard hat, I arrive pretty quickly at > the 'should run over UDP or TCP' exactly for these reasons. Obviously > a TCP implementation would do that vis a vis congestion, and > a UDP implementation would let you play games. This seems to be > pretty common, and I'd be surprised if we DON'T get there. > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jul 13 21:41:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14892 for ; Fri, 13 Jul 2001 21:41:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13519; Fri, 13 Jul 2001 21:40:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13490 for ; Fri, 13 Jul 2001 21:40:20 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14707 for ; Fri, 13 Jul 2001 21:39:28 -0400 (EDT) Received: from 157.54.7.67 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 13 Jul 2001 18:38:28 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 13 Jul 2001 18:38:03 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 13 Jul 2001 18:37:59 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 13 Jul 2001 18:37:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] London meeting time Date: Fri, 13 Jul 2001 18:37:01 -0700 Message-ID: Thread-Topic: [midcom] London meeting time Thread-Index: AcEL6r3sg/AjLPzySGy4+QMw2ObIhgAGgezA From: "Christian Huitema" To: , "Andrew Molitor" Cc: X-OriginalArrivalTime: 14 Jul 2001 01:37:01.0939 (UTC) FILETIME=[7AE6A430:01C10C05] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA13491 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit I am a great fan of designing protocols over UDP. However, we have to consider the practical problem of the packet size. Using IP fragmentation should be a big no-no -- it is a major source of problems as soon as the network systematically drops a fragment of each packet, and murphy's law says that in some cases it will. (In fact, we have practical examples.) Any protocol we do will have a strong security component; we will at some point have to carry certificate chains; certificate chains can absolutely be trusted to not fir in 512, 1260 or even 1500 bytes, either because the keys have grown long or because there are many elements in the chain. Frankly, I would feel much more confident if the main transport was TCP. > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Friday, July 13, 2001 3:08 PM > To: Andrew Molitor > Cc: midcom@ietf.org > Subject: Re: [midcom] London meeting time > > We've gotten into protocol selection/design. Perhaps this discussion > is a > bit early, but anyway... > > As anyone who followed the RSIP discussion knows, I have a very strong > bias AGAINST having an implementation be both TCP AND UDP. There are > two > and a half closely related reasons for this: > > 1. It's more code to write and maintain > > 2. Any lesser used code path is a potential security hazard, and > certainly a haven for bugs. > > 2.5 One of our touted reasons for success over other alternatives has > been > our LACK of options. > > Since the question is really what form should state remain, I am > inclined > to suggest that we decide which we need to guard more carefully- > latency > or the resources on the middlebox, while not trading off security, > pick > one and run with it. Let's not have another protocol that is both a > floor > wax AND a dessert topping. > > Eliot Lear > > Andrew Molitor wrote: > > > > On Thu, 12 Jul 2001, Melinda Shore wrote: > > > > > At 08:30 PM 7/11/01 -0500, Andrew Molitor wrote: > > > > My personal feelings are that UDP is the way to go, since > > > >TCP's backoff behavior is just not what you want in a real-time > > > >environment. > > > > > > I believe that all IETF protocols are now expected to employ > > > TCP-compatible congestion response mechanisms. That's not an > > > argument against using UDP, but it is something to be aware of. > > > > If I put on my standard hat, I arrive pretty quickly at > > the 'should run over UDP or TCP' exactly for these reasons. > Obviously > > a TCP implementation would do that vis a vis congestion, and > > a UDP implementation would let you play games. This seems to be > > pretty common, and I'd be surprised if we DON'T get there. > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www.ietf.org/mailman/listinfo/midcom > > -- > Eliot Lear > lear@cisco.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jul 13 23:37:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28735 for ; Fri, 13 Jul 2001 23:37:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA15613; Fri, 13 Jul 2001 23:36:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA15584 for ; Fri, 13 Jul 2001 23:36:32 -0400 (EDT) Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28579 for ; Fri, 13 Jul 2001 23:35:39 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id D64EA8115 for ; Fri, 13 Jul 2001 22:36:30 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id WAA00347 for ; Fri, 13 Jul 2001 22:36:30 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Fri, 13 Jul 2001 22:36:30 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] London meeting time In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Would I be burned at the stake for suggesting we declare transport Sombody Else's Problem, and simply make it a (strong) desideratum that the protocol be (efficiently) implementable over either TCP or UDP? I think if we did this, it would be necessary to demonstrate useful implementations over both before getting to RFC, but presumably it's possible to just say it initially. Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat Jul 14 01:32:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA15041 for ; Sat, 14 Jul 2001 01:32:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26118; Sat, 14 Jul 2001 01:32:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26087 for ; Sat, 14 Jul 2001 01:32:22 -0400 (EDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14733 for ; Sat, 14 Jul 2001 01:31:30 -0400 (EDT) Received: from localhost (elear@localhost) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id WAA25622; Fri, 13 Jul 2001 22:31:49 -0700 (PDT) Date: Fri, 13 Jul 2001 22:31:49 -0700 (PDT) From: Eliot Lear To: Andrew Molitor cc: midcom@ietf.org Subject: RE: [midcom] London meeting time In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org As far as requirements are concerned, state the requirements, and let the proposed solutions sweat on how to fulfill them. On Fri, 13 Jul 2001, Andrew Molitor wrote: > Would I be burned at the stake for suggesting we declare > transport Sombody Else's Problem, and simply make it a (strong) > desideratum that the protocol be (efficiently) implementable over > either TCP or UDP? > > I think if we did this, it would be necessary to demonstrate > useful implementations over both before getting to RFC, but presumably > it's possible to just say it initially. > > Andrew > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat Jul 14 01:36:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16256 for ; Sat, 14 Jul 2001 01:36:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26220; Sat, 14 Jul 2001 01:36:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26188 for ; Sat, 14 Jul 2001 01:36:46 -0400 (EDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA15990 for ; Sat, 14 Jul 2001 01:35:55 -0400 (EDT) Received: from localhost (elear@localhost) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id WAA26621; Fri, 13 Jul 2001 22:36:15 -0700 (PDT) Date: Fri, 13 Jul 2001 22:36:15 -0700 (PDT) From: Eliot Lear To: Christian Huitema cc: lear@cisco.com, Andrew Molitor , midcom@ietf.org Subject: RE: [midcom] London meeting time In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Christian, I am NOT going to stand on my head to argue for UDP at this point in time. I would vastly prefer TCP over having to do both. But in any event, why not we write down the underlying requirements (e.g., large #s of transactions per second) and let the candidate protocols fulfill them? Eliot On Fri, 13 Jul 2001, Christian Huitema wrote: > I am a great fan of designing protocols over UDP. However, we have to > consider the practical problem of the packet size. Using IP > fragmentation should be a big no-no -- it is a major source of problems > as soon as the network systematically drops a fragment of each packet, > and murphy's law says that in some cases it will. (In fact, we have > practical examples.) Any protocol we do will have a strong security > component; we will at some point have to carry certificate chains; > certificate chains can absolutely be trusted to not fir in 512, 1260 or > even 1500 bytes, either because the keys have grown long or because > there are many elements in the chain. Frankly, I would feel much more > confident if the main transport was TCP. > > > -----Original Message----- > > From: Eliot Lear [mailto:lear@cisco.com] > > Sent: Friday, July 13, 2001 3:08 PM > > To: Andrew Molitor > > Cc: midcom@ietf.org > > Subject: Re: [midcom] London meeting time > > > > We've gotten into protocol selection/design. Perhaps this discussion > > is a > > bit early, but anyway... > > > > As anyone who followed the RSIP discussion knows, I have a very strong > > bias AGAINST having an implementation be both TCP AND UDP. There are > > two > > and a half closely related reasons for this: > > > > 1. It's more code to write and maintain > > > > 2. Any lesser used code path is a potential security hazard, and > > certainly a haven for bugs. > > > > 2.5 One of our touted reasons for success over other alternatives has > > been > > our LACK of options. > > > > Since the question is really what form should state remain, I am > > inclined > > to suggest that we decide which we need to guard more carefully- > > latency > > or the resources on the middlebox, while not trading off security, > > pick > > one and run with it. Let's not have another protocol that is both a > > floor > > wax AND a dessert topping. > > > > Eliot Lear > > > > Andrew Molitor wrote: > > > > > > On Thu, 12 Jul 2001, Melinda Shore wrote: > > > > > > > At 08:30 PM 7/11/01 -0500, Andrew Molitor wrote: > > > > > My personal feelings are that UDP is the way to go, since > > > > >TCP's backoff behavior is just not what you want in a real-time > > > > >environment. > > > > > > > > I believe that all IETF protocols are now expected to employ > > > > TCP-compatible congestion response mechanisms. That's not an > > > > argument against using UDP, but it is something to be aware of. > > > > > > If I put on my standard hat, I arrive pretty quickly at > > > the 'should run over UDP or TCP' exactly for these reasons. > > Obviously > > > a TCP implementation would do that vis a vis congestion, and > > > a UDP implementation would let you play games. This seems to be > > > pretty common, and I'd be surprised if we DON'T get there. > > > > > > _______________________________________________ > > > midcom mailing list > > > midcom@ietf.org > > > http://www.ietf.org/mailman/listinfo/midcom > > > > -- > > Eliot Lear > > lear@cisco.com > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www.ietf.org/mailman/listinfo/midcom > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat Jul 14 02:35:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03202 for ; Sat, 14 Jul 2001 02:35:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27353; Sat, 14 Jul 2001 02:35:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27319 for ; Sat, 14 Jul 2001 02:35:51 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03123 for ; Sat, 14 Jul 2001 02:34:59 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6CJOjt13673; Thu, 12 Jul 2001 12:24:45 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn2-51.cisco.com [10.21.112.51]) by airborne.cisco.com (Mirapoint) with ESMTP id AGI06425; Thu, 12 Jul 2001 12:24:34 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.94 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15181.63856.914000.663665@gargle.gargle.HOWL> Date: Thu, 12 Jul 2001 15:24:32 -0400 To: "Fernando Cuervo" Cc: "'Christian Huitema'" , Andrew Molitor , midcom Subject: RE: [midcom] London meeting time In-Reply-To: References: Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit What about SCTP? _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat Jul 14 09:03:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13743 for ; Sat, 14 Jul 2001 09:03:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04747; Sat, 14 Jul 2001 09:01:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04719 for ; Sat, 14 Jul 2001 09:01:50 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13428 for ; Sat, 14 Jul 2001 09:00:57 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6ED1MU28203; Sat, 14 Jul 2001 06:01:22 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp237.cisco.com [10.21.64.237]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id APT00383; Sat, 14 Jul 2001 06:01:10 -0700 (PDT) Message-Id: <5.1.0.14.0.20010714085848.00a27ec0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 14 Jul 2001 09:02:19 -0400 To: Andrew Molitor , midcom@ietf.org From: Melinda Shore Subject: RE: [midcom] London meeting time In-Reply-To: References: 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 10:36 PM 7/13/01 -0500, Andrew Molitor wrote: > Would I be burned at the stake for suggesting we declare >transport Sombody Else's Problem, and simply make it a (strong) >desideratum that the protocol be (efficiently) implementable over >either TCP or UDP? I'm not sure how many times it has to be repeated, so I'll do it again just for the heck of it: WE ARE NOT SPECIFYING MECHANISM IN THESE DOCUMENTS. "Runs over TCP" is not a requirement. "Transport must provide assured delivery" is a requirement. Thank you, and the next person who tries to discuss whether we'll run over TCP or UDP or AAL5 owes me a drink - an expensive one - in London. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat Jul 14 12:57:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09260 for ; Sat, 14 Jul 2001 12:57:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08220; Sat, 14 Jul 2001 12:55:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08190 for ; Sat, 14 Jul 2001 12:55:49 -0400 (EDT) Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08996 for ; Sat, 14 Jul 2001 12:54:57 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id 00BE78104 for ; Sat, 14 Jul 2001 11:35:55 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id LAA18818 for ; Sat, 14 Jul 2001 11:35:55 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Sat, 14 Jul 2001 11:35:55 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] London meeting time In-Reply-To: <5.1.0.14.0.20010714085848.00a27ec0@mira-sjc5-4.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Sat, 14 Jul 2001, Melinda Shore wrote: > At 10:36 PM 7/13/01 -0500, Andrew Molitor wrote: > > Would I be burned at the stake for suggesting we declare > >transport Sombody Else's Problem, and simply make it a (strong) > >desideratum that the protocol be (efficiently) implementable over > >either TCP or UDP? > > I'm not sure how many times it has to be repeated, so I'll do > it again just for the heck of it: WE ARE NOT SPECIFYING MECHANISM > IN THESE DOCUMENTS. My apologies, I thought it was clear that I meant declaring transport somebody else's problem in ALL midcom documents, not just the ones where it's perfectly clear to everyone that such discussion has no place. I keep assuming that everyone knows I'm not an idiot, and that they will therefore interpret my remarks in that light. My bad. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 16 10:27:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19442 for ; Mon, 16 Jul 2001 10:27:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09411; Mon, 16 Jul 2001 10:25:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09385 for ; Mon, 16 Jul 2001 10:25:05 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18694 for ; Mon, 16 Jul 2001 10:24:12 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6GEOH925188 for ; Mon, 16 Jul 2001 10:24:17 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Mon, 16 Jul 2001 10:24:16 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <3HJ26ADF>; Mon, 16 Jul 2001 10:24:18 -0400 Message-ID: From: "Fernando Cuervo" To: "'Fleischman, Eric W'" , "'Christian Huitema'" , Andrew Molitor , midcom Subject: RE: [midcom] London meeting time Date: Mon, 16 Jul 2001 10:24:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10E02.FAEAF470" 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_01C10E02.FAEAF470 Content-Type: text/plain I'm using the transaction term in the sense of a request-reply mechanism that can in addition provide "in-progress" status or accept "abort" commands. Further a transaction may contain several service request to a midcom box that may need to be processed together or not at all. Fernando Cuervo > -----Original Message----- > From: Fleischman, Eric W [SMTP:Eric.Fleischman@PSS.Boeing.com] > Sent: Thursday, July 12, 2001 4:16 PM > To: Cuervo, Fernando [CAR:5N10:EXCH]; 'Christian Huitema'; Andrew > Molitor; midcom > Subject: RE: [midcom] London meeting time > > It isn't clear to me what a "transaction" means to the Midcom WG. > My own use of the term is directly influenced by application > layer concerns and explicitly includes two phased commits (e.g., for > databases and transactional systems). But some may use the term in > the sense of "agreement instance between the midcom agent and the > middlebox". Which meaning is being used here? Specifically, are > we proposing that two-phased commit semantics be used for Midcom? > If so, why? > > -----Original Message----- > From: Fernando Cuervo [mailto:cuervo@nortelnetworks.com] > Sent: Thursday, July 12, 2001 11:29 AM > To: 'Christian Huitema'; Andrew Molitor; midcom > Subject: RE: [midcom] London meeting time > > > There are two separate issues around the choice of transport: > 1-security implications: If TCP and UDP are to be allowed then a security > element in the protocol or use IPSec are needed > 2-transaction capabilities: given that the issue is reliability the use of > UDP requires that timers and retransmissions to be handled by the > protocol. However, regardless of TCP or UDP things such as transaction in > progress or even an abort command (to handle the open/close pin-hole > scenario) may be useful, therefore it would be wise to leave all > transaction control to the protocol, which is compatible with the dual use > of TCP and UDP. > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C10E02.FAEAF470 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [midcom] London meeting time

I'm using the = transaction term in the sense of a request-reply mechanism that can = in
addition provide = "in-progress" status or accept "abort" commands. = Further a
transaction may = contain several service request to a midcom box that may need to = be
processed together = or not at all.

Fernando = Cuervo

    -----Original Message-----
    From:   Fleischman, Eric W = [SMTP:Eric.Fleischman@PSS.Boeing.com]
    Sent:   Thursday, July 12, 2001 4:16 PM
    To:     Cuervo, Fernando [CAR:5N10:EXCH]; 'Christian Huitema'; = Andrew Molitor; midcom
    Subject:       = RE: [midcom] London meeting = time

    It isn't clear to me what a = "transaction" means to the Midcom WG.
    My own use of the term is directly = influenced by application
    layer concerns and explicitly = includes two phased commits (e.g., for
    databases and transactional systems). = But some may use the term in
    the sense of "agreement instance = between the midcom agent and the
    middlebox". Which meaning is = being used here? Specifically, are
    we proposing that two-phased commit = semantics be used for Midcom?
    If so, why?

    -----Original Message-----
    From: Fernando Cuervo = [mailto:cuervo@nortelnetworks.c= om]
    Sent: Thursday, July 12, 2001 11:29 = AM
    To: 'Christian Huitema'; Andrew = Molitor; midcom
    Subject: RE: [midcom] London meeting = time


    There are two separate issues around = the choice of transport:
    1-security implications: If TCP and = UDP are to be allowed then a security element in the protocol or use = IPSec are needed

    2-transaction capabilities: given that = the issue is reliability the use of UDP requires that timers and = retransmissions to be handled by the protocol. However, regardless of = TCP or UDP things such as transaction in progress or even an abort = command (to handle the open/close pin-hole scenario) may be useful, = therefore it would be wise to leave all transaction control to the = protocol, which is compatible with the dual use of TCP and = UDP.

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

------_=_NextPart_001_01C10E02.FAEAF470-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 16 10:27:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19469 for ; Mon, 16 Jul 2001 10:27:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09453; Mon, 16 Jul 2001 10:25:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09424 for ; Mon, 16 Jul 2001 10:25:12 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18717 for ; Mon, 16 Jul 2001 10:24:19 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6GEOO925204 for ; Mon, 16 Jul 2001 10:24:25 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 16 Jul 2001 10:24:26 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <3HJ26ADK>; Mon, 16 Jul 2001 10:24:29 -0400 Message-ID: From: "Fernando Cuervo" To: "'Scott Brim'" Cc: "'Christian Huitema'" , Andrew Molitor , midcom Subject: RE: [midcom] London meeting time Date: Mon, 16 Jul 2001 10:24:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10E03.02BDABC0" 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_01C10E03.02BDABC0 Content-Type: text/plain SCTP is an interesting alternative, I have not kept up with the details, but a way back when Megaco and SCTP we emerging this seemed to me a reasonable way to handle the transaction requirements...It's probably worth looking into it. Fernando Cuervo > -----Original Message----- > From: Scott Brim [SMTP:sbrim@cisco.com] > Sent: Thursday, July 12, 2001 3:25 PM > To: Cuervo, Fernando [CAR:5N10:EXCH] > Cc: 'Christian Huitema'; Andrew Molitor; midcom > Subject: RE: [midcom] London meeting time > > What about SCTP? > ------_=_NextPart_001_01C10E03.02BDABC0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [midcom] London meeting time

SCTP is an = interesting alternative, I have not kept up with the details, but a way = back when
Megaco and SCTP we = emerging this seemed to me a reasonable way to handle the = transaction
requirements...It's = probably worth looking into it.

Fernando = Cuervo

    -----Original Message-----
    From:   Scott Brim [SMTP:sbrim@cisco.com]
    Sent:   Thursday, July 12, 2001 3:25 PM
    To:     Cuervo, Fernando [CAR:5N10:EXCH]
    Cc:     'Christian Huitema'; Andrew Molitor; midcom
    Subject:       = RE: [midcom] London meeting = time

    What about SCTP?

------_=_NextPart_001_01C10E03.02BDABC0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 16 10:27:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19504 for ; Mon, 16 Jul 2001 10:27:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09372; Mon, 16 Jul 2001 10:24:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09347 for ; Mon, 16 Jul 2001 10:24:56 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18636 for ; Mon, 16 Jul 2001 10:24:02 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6GEO7925119 for ; Mon, 16 Jul 2001 10:24:07 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 16 Jul 2001 10:24:07 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <3HJ26ADC>; Mon, 16 Jul 2001 10:24:10 -0400 Message-ID: From: "Fernando Cuervo" To: "'Melinda Shore'" , "'Christian Huitema'" , Andrew Molitor , midcom Subject: RE: [midcom] London meeting time Date: Mon, 16 Jul 2001 10:24:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10E02.F746CBA0" 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_01C10E02.F746CBA0 Content-Type: text/plain Let me put it this way... the transaction requirements level the playing field for TCP vs. UDP. Implementing both will give you more choice for security mechanisms. I agree with Christian's concern about fragmentation...how we handle fragmentation might be the deciding factor... Fernando Cuervo > -----Original Message----- > From: Melinda Shore [SMTP:mshore@cisco.com] > Sent: Thursday, July 12, 2001 2:52 PM > To: Cuervo, Fernando [CAR:5N10:EXCH]; 'Christian Huitema'; Andrew > Molitor; midcom > Subject: RE: [midcom] London meeting time > > At 02:28 PM 7/12/01 -0400, Fernando Cuervo wrote: > >There are two separate issues around the choice of transport: > >1-security implications: If TCP and UDP are to be allowed then a security > element in the protocol or use IPSec are needed > > > >2-transaction capabilities: given that the issue is reliability the use > of UDP requires that timers and retransmissions to be handled by the > protocol. However, regardless of TCP or UDP things such as transaction in > progress or even an abort command (to handle the open/close pin-hole > scenario) may be useful, therefore it would be wise to leave all > transaction control to the protocol, which is compatible with the dual use > of TCP and UDP. > > Not to be tiresome, but we are not choosing a transport. We need > to describe the characteristics we require of the transport. > > Melinda > > ------_=_NextPart_001_01C10E02.F746CBA0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [midcom] London meeting time

Let me put it this = way... the transaction requirements level the playing field for TCP vs. = UDP.
Implementing both = will give you more choice for security mechanisms. I agree with = Christian's
concern about = fragmentation...how we handle fragmentation might be the deciding = factor...

Fernando = Cuervo

    -----Original Message-----
    From:   Melinda Shore [SMTP:mshore@cisco.com]
    Sent:   Thursday, July 12, 2001 2:52 PM
    To:     Cuervo, Fernando [CAR:5N10:EXCH]; 'Christian Huitema'; = Andrew Molitor; midcom
    Subject:       = RE: [midcom] London meeting = time

    At 02:28 PM 7/12/01 -0400, Fernando = Cuervo wrote:
    >There are two separate issues = around the choice of transport:
    >1-security implications: If TCP = and UDP are to be allowed then a security element in the protocol or = use IPSec are needed

    >
    >2-transaction capabilities: given = that the issue is reliability the use of UDP requires that timers and = retransmissions to be handled by the protocol. However, regardless of = TCP or UDP things such as transaction in progress or even an abort = command (to handle the open/close pin-hole scenario) may be useful, = therefore it would be wise to leave all transaction control to the = protocol, which is compatible with the dual use of TCP and = UDP.

    Not to be tiresome, but we are not = choosing a transport.  We need
    to describe the characteristics we = require of the transport.

    Melinda


------_=_NextPart_001_01C10E02.F746CBA0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 17 11:23:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29125 for ; Tue, 17 Jul 2001 11:23:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23882; Tue, 17 Jul 2001 11:20:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23850 for ; Tue, 17 Jul 2001 11:20:10 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28420 for ; Tue, 17 Jul 2001 11:19:14 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6HFHlH21167 for ; Tue, 17 Jul 2001 08:17:49 -0700 (PDT) Received: from NAUGA (dhcp-128-107-166-36.cisco.com [128.107.166.36]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AQG06179; Tue, 17 Jul 2001 08:19:28 -0700 (PDT) Message-ID: <063b01c10ed3$cab06250$24a66b80@NAUGA> From: "Melinda Shore" To: Date: Tue, 17 Jul 2001 11:18:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [midcom] Schedule update Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit We've been moved to 9-11:30 Friday, 10 August. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 17 13:52:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02440 for ; Tue, 17 Jul 2001 13:52:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29915; Tue, 17 Jul 2001 13:49:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28865 for ; Tue, 17 Jul 2001 13:27:39 -0400 (EDT) Received: from roam.psg.com (H-135-207-10-122.research.att.com [135.207.10.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26319; Tue, 17 Jul 2001 13:26:36 -0400 (EDT) Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MYb7-0000LK-00; Tue, 17 Jul 2001 13:25:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rsent-To: eos@ops.ietf.org From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Message-Id: Date: Tue, 17 Jul 2001 13:25:25 -0400 Content-Transfer-Encoding: 7bit Subject: [midcom] Note Well Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 17 14:15:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08334 for ; Tue, 17 Jul 2001 14:15:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01616; Tue, 17 Jul 2001 14:13:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00148 for ; Tue, 17 Jul 2001 13:57:26 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23758; Tue, 17 Jul 2001 13:16:53 -0400 (EDT) Message-Id: <200107171716.NAA23758@ietf.org> From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Date: Tue, 17 Jul 2001 13:16:53 -0400 Subject: [midcom] Note Well Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jul 18 15:37:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12695 for ; Wed, 18 Jul 2001 15:37:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00208; Wed, 18 Jul 2001 15:35:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00176 for ; Wed, 18 Jul 2001 15:35:28 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12043 for ; Wed, 18 Jul 2001 15:34:32 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6IJX9c25478 for ; Wed, 18 Jul 2001 12:33:11 -0700 (PDT) Received: from NAUGA (dhcp-128-107-166-36.cisco.com [128.107.166.36]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id AQK10618; Wed, 18 Jul 2001 12:34:50 -0700 (PDT) Message-ID: <00f401c10fc0$a3583910$24a66b80@NAUGA> From: "Melinda Shore" To: Date: Wed, 18 Jul 2001 15:34:16 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00F1_01C10F9F.1A6B7070" 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 Subject: [midcom] Fw: I-D ACTION:draft-martin-network-sip-natfw-callflows-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_00F1_01C10F9F.1A6B7070 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit FYI, for those not on ietf-announce. Melinda ----- Original Message ----- From: To: Sent: Wednesday, July 18, 2001 7:00 AM Subject: I-D ACTION:draft-martin-network-sip-natfw-callflows-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : SIP Through NAT Enabled Firewall Call Flows > Author(s) : C. Martin, A. Johnston > Filename : draft-martin-network-sip-natfw-callflows-00.txt > Pages : > Date : 17-Jul-01 > > This informational draft outlines the operation of a SIP enabled > NAPT (often referred to as PAT)/firewall ALG which makes > modifications to SIP (Session Initiation Protocol)[2] headers and > SDP (Session Description Protocol)[3] fields. Both inbound and > outbound detailed call flows are included. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-martin-network-sip-natfw-callflows -00.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-martin-network-sip-natfw-callflows-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-martin-network-sip-natfw-callflows-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ------=_NextPart_000_00F1_01C10F9F.1A6B7070 Content-Type: application/octet-stream; name="ATT00236.dat" Content-Disposition: attachment; filename="ATT00236.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20010717133455.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-martin-network-sip-natfw-callflows-00.txt ------=_NextPart_000_00F1_01C10F9F.1A6B7070 Content-Type: text/plain; name="draft-martin-network-sip-natfw-callflows-00.txt" Content-Disposition: attachment; filename="draft-martin-network-sip-natfw-callflows-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20010717133455.I-D@ietf.org> ------=_NextPart_000_00F1_01C10F9F.1A6B7070-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jul 20 13:25:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05855 for ; Fri, 20 Jul 2001 13:25:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09122; Fri, 20 Jul 2001 13:18:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09089 for ; Fri, 20 Jul 2001 13:18:53 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03854 for ; Fri, 20 Jul 2001 13:17:57 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6KHIV311709 for ; Fri, 20 Jul 2001 10:18:31 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp42.cisco.com [10.21.64.42]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AQY14625; Fri, 20 Jul 2001 10:18:20 -0700 (PDT) Message-Id: <5.1.0.14.0.20010720131633.00a672d0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 20 Jul 2001 13:19:29 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Framework last call Sender: 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 midcom framework document (available as http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-03.txt is ready for working group last call. Last call closes Friday, 3 August 2001. Please send all comments to the midcom mailing list. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jul 20 16:24:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05863 for ; Fri, 20 Jul 2001 16:24:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16307; Fri, 20 Jul 2001 16:15:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16275 for ; Fri, 20 Jul 2001 16:15:24 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01299 for ; Fri, 20 Jul 2001 16:14:26 -0400 (EDT) Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PDZ55Y45; Fri, 20 Jul 2001 16:14:51 -0400 Message-Id: <3.0.5.32.20010720153341.0085e990@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 20 Jul 2001 15:33:41 -0400 To: midcom@ietf.org, srisuresh@yahoo.com, kuthan@fokus.gmd.de, jdrosen@dynamicsoft.com, amolitor@visi.com, ar_rayhan@yahoo.ca From: Mark Duffy Subject: Re: [midcom] Framework last call In-Reply-To: <5.1.0.14.0.20010720131633.00a672d0@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, I have some comments and suggestions on draft-ietf-midcom-framework-03.txt. . The document should make a clear statement on what in a packet the middlebox is expected to understand and be able to classify on. I hope this is only IP header fields and TCP/UDP port numbers. (Thus the middlebox would be "IP-aware" and "TCP/UDP-aware" but not "application-aware".) There was the long discussion on the maiiling list about being BEEP-aware but I'm not sure what the consensus was (if any). . The document should make a clear statement on what in a packet the middlebox may modify. My understanding is this should be only the IP header and TCP/UDP port numbers (and associated checksums). The requirements draft states this in section 4.1 although it is vague about what constitutes the "packet header". My understanding is only the Midcom Agent should modify any higher layer information. . In section 1. Introduction, 1st paragraph, it says "The discussion scope of this document is however limited to middleboxes implementing Firewall and NAT services only." This improperly (I believe) excludes middleboxes implementing other services but doing so outside of the midcom framework. I suggest rewording this as "The discussion scope of this document is however limited to firewall and NAT middlebox services." . In 2.1 it says "A middlebox function or a middlebox service is an operation or method performed by a network intermediary that requires application specific intelligence for its operation." I propose replacing "requires application specific intelligence" with "may require application specific intelligence". For example, if a firewall device were set up to pass all TCP packets but drop all non-TCP packets, that would not require application specific intelligence. Would it not however still be considered a middlebox function? . 2.4 -- NAT. "Network Address Translation is a method by which IP addresses are mapped from one address realm ..." I suggest this should mention port numbers as well i.e. "Network Address Translation is a method by which IP addresses and TCP/UDP port numbers are mapped ..." . In 3.0 beneath the figure it introduces the concept of SessionDirection. The implication I get is that this identifies either "outbound" or "inbound". This may become limiting. For example, in a service provider based middlebox there may be "in" sides associated with each customer of the provider. While this could be modeled as many logical middleboxes each with an inside and outside, it would be much more flexible for the midcom architecture to provide for this. One way to do this would be to enlarge the Session-Descriptor tuple to also specify the applicable interface. Another way would be to allow for specifying in the tuple which realms the packet is moving from and to (although I don't know of any existing way to name and refer to these realms). (Section 8.1 relates to this somewhat.) . In 3.0 below the figure it states "The attributes associated with a Session-Descriptor may be specific to the individual middlebox function." Can you please clarify the meaning of this? What *are* the "attributes"? Are they the what-to-do-when-a-packet-matches-this-session-descriptor stuff? . In 5.0 it states "In-Path MIDCOM agents are entities that have a native role in the path of the application traversal ... idependent of their MIDCOM function." Why must they have a native role? This would pretty much eliminate using midcom for any applications that don't already employ such devices. I don't see any reason to exclude agent devices placed there solely for the purpose of being an in-path Midcom Agent. I propose we revise that sentence to read: "In-Path MIDCOM agents are MIDCOM agents that are located naturally within the message path of the application they are associated with." Or strike the sentence entirely since this is just repeating the definition presented in section 2.8. . In the last paragraph on Page 10 (section 5.0) it uses the words interjecting/interjected. Those should be replaced by intercepting/intercepted. (It is talking here about the agent receiving and manipulating packets already in-flight, not about introducing new packets.) . In section 6.1: "Simple Source-address based security is the least form of security in a trusted domain and may be permitted to trusted hosts." It doesn't matter how trusted the hosts are if someone can spoof them! I propose changing the wording to "Simple Source-address based security is a minimal form of security and should be relied on only in the most trusted environments where those hosts won't be spoofed." . Section 6.2 -- registration. It is not clear what "registration" means in the midcom context and I think this should be clarified in the document. By my read it refers to configuring information about the agent into the middlebox or entering similar information into the policy server(s). If this is what it means than this is probably something done *on behalf of the agent* by some operator, rather than *by the agent itself*. If this is the case it doesn't make sense to me that the agent would "deregister" itself as described in the last paragraph of 6.2 -- that seems to relate to breaking the current session. We need to define "registration" and how it relates to one or the other of - provisioning of authorization information, or - establishment of an authenticated session between an authorized agent and a middlebox. Section 6.2, "Coupling MIDCOM agents with the middlebox resources requires a means of reflecting that into the resource description table of the middlebox. In the case of a firewall, for example, the ACL tuple may be altered to reflect the optional ALG presence. The revised ACL may look something like the following. (, , , , , , ) Can you please clarify this? Aside from the that tuple appears to be a specification for identifying a set of packets. I don't see what an ALG has to do with that. Besides, isn't it a fundamental concept of midcom that the ALG belongs in the agent, not in the middlebox? . Section 8.4 -- timers: "However, the middlebox should be able to recover the dynamically allocated resources even as the agent that was responsible for the allocation is not alive." Does that mean "recover even while still alive" or "recover when not alive"? . Separate from any timers on individual resources, there should be a way to detect disappearance of the agent. That disappearance should perhaps free all the related resources as stated in draft-ietf-midcom-requirements-01 section 5.3.2. (Or was there a decision on the mailing list that disappearance of the Agent not cause all its allocated resources to be immediately freed?) Why should the middlebox time out allocated resources while the session with the agent is still alive? But if it does so, it should notify the agent! . Section 8.5: " In the case of a middlebox implementing NAT and firewall services, it is safe to state that the NAT operation will precede firewall on the egress and will follow firewall on the ingress." From what frame of reference are we defining egress and ingress? Please clarify. If this is egress from and ingress to the private domain, then I disagree with this statement. I believe the firewall rules must be based on the private addresses etc. (which are fixed and known), not on the public addresses (which are dynamically assigned). In fact I believe this is what the next sentence in 8.5 means: "Further, firewall access control lists used by a firewall are assumed to be based on session parameters as seen on the interface supporting firewall service." . There is no section between 9 and 11. . Section 12 -- security considerations: "The premise of middlebox operation fundamentally requires the data to be in the clear as the middlebox needs the ability to inspect and/or modify packet headers and payload." I believe what you are referring to here is a pre-midcom world, as contrasted by the next paragraph. It would help to state here explicitly that this refers to the world without midcom. . Section 12, last paragraph on Page 32: " A middlebox service may be abruptly disrupted due to malicious manipulation or incorrect implementation of the middlebox or its agents of a certain shared resource by an agent purporting to offer ALG service for a different middlebox function." This is very hard to understand. For me anyway :-) Here is a suggested rewording: "A middlebox service may be disrupted due to conflicting directives from multiple agents associated with different middlebox functions but applied to the same application session." -- Thanks, Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jul 20 18:10:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08944 for ; Fri, 20 Jul 2001 18:10:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19880; Fri, 20 Jul 2001 18:05:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19853 for ; Fri, 20 Jul 2001 18:05:06 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06418 for ; Fri, 20 Jul 2001 18:04:10 -0400 (EDT) Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PDZ55YZQ; Fri, 20 Jul 2001 18:04:35 -0400 Message-Id: <3.0.5.32.20010720172906.008fab50@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 20 Jul 2001 17:29:06 -0400 To: midcom@ietf.org, richard.swale@bt.com, sijben@lucent.com, philip.mart@marconi.com From: Mark Duffy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] comments on midcom-requirements-01 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi, I have some comments and questions on draft-ietf-midcom-requirements-01.txt. I know this draft has been out for a while so my apologies if I am raising questions on any "stale" material. 1. In general, there is a lot of overlap between this document and the framework document. I would suggest restricting this document to only the actual protocol requirements (more or less section 5 on). 2. In section 4.1, "a Middlebox forwards packets from one of its physical interfaces to another." I suggest that should refer to logical (IP) interfaces rather than physical. 3. In section 5.1,it states that "applications may require... translation of IP addresses... and knowledge of the specific translations used". In fact, applications do not require this and cannot get this knowledge unless they happen to be acting as the Midcom Agent. Rather, operation of the application through the middlebox may require the translation of IP addresses etc. And it is the Midcom Agent that may require knowledge of the specific translations used. I propose replacing "Applications may require ..." with "Midcom agents may request...". 4. Regarding the agent having knowledge of the specific translations used, is there any requirement that the agent be able to *control* the translations used??? I think in general the middlebox itself needs to be in control of allocating any address/port bindings, but are there applications where multiple packet flows associated with the same application instance must be assigned the same address, for the application to work correctly? If so, the midcom protocol must allow the agent to request this of the middlebox. 5. In 5.2.1, 2nd paragraph, it says "The attributes associated with a Pinhole-Descriptor may be specific to a given Middlebox or MIDCOM Agent." Can you please clarify what this means? To what 'attributes' does this refer? If it refers to (direction, SA, DA, protocol, SP, DP) than those should be specific to an application but not to a given middlebox or agent! 6. Also in 5.2.1, I believe that pinhole specification should be specified by "DSCP field" (high 6 bits of the old TOS octet) rather than by the now-obsolete "TOS field". This is probably also true for IPv6 traffic class field. 7. At the end of 5.2.1 it says that the midcom protocol needs to convey directives to the middlebox on how to rewrite header fields such as addresses and port numbers. How is the agent to know what addresses/ports may be assigned? Since the agents are distributed I think it must be the middlebox that controls the allocation of these. (Perhaps subject to some influence from the agent per my comment #4 above.) 8. 5.3.2 Close Pin-Hole. Is it still the intent that only the agent that created a pinhole can close it? I recall some discussion about this on the list but I don't recall the conclusion. This would be an impediment to distributed/redundant agents, but is also a factor in how/whether pinholes are timed out. 9. Also relative to closing pinholes, if they are not to be automatically closed when losing connectivity with the requsting agent, then I think there should be a mechanism for identifying stale pinhole identifiers (as presented by an agent to a middlebox or vice-versa) so that the devices can discard requests for actions on those pinholes. This could be sequence numbers or qualifying the pinhole identifier with the identity of the owning Midcom Agent. 10. Section 6.1 seems to embody a different concept of "registration" than the framework draft. From my read of the framework, registration is the process of configuring a particular agent into either the middlebox or policy server as an authorized agent. The agent and the middlebox may then authenticate each other each time they want to have a session between themselves. In this requirements draft "registration" seems to refer to the mutual authentication. The concepts of registration, authorization, authentication, and the middlebox-agent session establishment need to be more clearly delineated. 11. Section 7, 7.1.1, 11.2, and 4.1(3rd paragraph) -- is this all obsolete text describing diversion of packets to an OOP agent, and slated for removal? 12. 7.1 "A MIDCOM Agent shall be able to request a pin-hole from a Middlebox for the purposes of establishing a presence on the external network." -- I don't understand what is meant by "establishing a presence on the external network". Perhaps this should say "... purposes of allowing communication to or from the external network". 13. 7.1 "The MIDCOM communication protocol needs to allow for selective communication between a specific MIDCOM agent and one or more Middlebox functions on the interface to which it is connected." -- why only "on the interface to which it is connected"? It seems to me the pinholes may need to apply to interfaces other than the one(s) via which the agent communicates with the middlebox. 14. 10.4, 2nd paragraph: "The MIDCOM Protocol shall describe the desired behaviour of the Middlebox for the purposes of a requested flow(s)." This paragraph does not seem to belong in this section which is about authentication requirements. 15. Section 10.5 MIDCOM Policy Requirements. I'm confused by this section which discusses a protocol between midcom *agents* and policy servers. The framework document discusses communication between the middlebox and policy servers but not between the agents and policy servers. And that protocol is presumably out of the scope of this document anyway. I suggest removing section 10.5. 16. Section 10.7 -- protocol reliability. It is highly desirable for redundant-hardware implementations that midcom sessions (i.e. midcom-level shared state) between an agent and a middlebox be able to survive restarts of the transport layer connection. At least, if the transport layer is TCP or a protocol that is similarly difficult to support across a control plane hardware failover. Work is underway in the IETF to address this for BGP and LDP. I think it is also important for midcom. 17. In section 12: "Simple Source-address based security is the least form of security and should be permitted only to the most trusted hosts." It doesn't matter how trusted the hosts are if someone can spoof them. I propose changing the wording to "... is a minimal form of security and should be permitted only in the most trusted environments where those hosts won't be spoofed." 18. Section 12: "The MIDCOM protocol must enable a trust relationship to be established between a specific MIDCOM Agent and a specific Middlebox for the purposes of permitting flows between the hosts that flow via the Middlebox." This is quite confusing, and it only seems to cover pinholes not any other middlebox services. I propose changing the wording to "... for the purposes of permitting midcom operations to be performed only in response to authentic and authorized requests." 19. Section 12. through 12.1.2. This whole discussion of trusted and un-trusted agents is confusing. It seems to state clearly that the middlebox should only accept requests from trusted agents but it also talks about untrusted agents. Is an untrusted agent just one we don't trust *yet*, or you trying to allow for a sort of "connectionless trust"? If the former the wording should be improved. If the latter, I don't see how this would work given the requirements (e.g. in section 6.2) to close pinholes etc when the relationship (trust?) with the peer goes away. Overall, the terms trust and trust relationship are overused in the industry and poorly defined. It might be more clear not to use those terms here at all and instead talk in terms of authentication and authorization. 20. Section 12.2 item b. "Allow for preservation of the control messages once the association has been established." I'm not sure what preservation means. Can this be reworded to "Allow for protection of integrity of the control messages..."? -- Thanks, Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Jul 22 07:29:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08056 for ; Sun, 22 Jul 2001 07:29:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19653; Sun, 22 Jul 2001 07:27:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19624 for ; Sun, 22 Jul 2001 07:27:52 -0400 (EDT) Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07554 for ; Sun, 22 Jul 2001 07:26:55 -0400 (EDT) From: richard.swale@bt.com Received: from cbtlipnt01.btlabs.bt.co.uk by gandalf (local) with ESMTP; Sun, 22 Jul 2001 12:27:17 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Sun, 22 Jul 2001 12:26:28 +0100 Message-ID: To: mduffy@quarrytech.com, midcom@ietf.org, sijben@lucent.com, philip.mart@marconi.com Date: Sun, 22 Jul 2001 12:25:46 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Subject: [midcom] RE: comments on midcom-requirements-01 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Mark, Thanks for your comments - and no it isn't too late to be raising some of the points you make (actually it is very welcome!). I have embedded some comments below. If the list gets wildly active on the response, I suggest we break them down into specific issues. So here goes...... > > 1. In general, there is a lot of overlap between this > document and the > framework document. I would suggest restricting this > document to only the > actual protocol requirements (more or less section 5 on). This is true. However there is a need to focus in on the specific environment of the protocol - the framework, from my last reading, the much wider context of the problem MIDCOM is trying to address. > > 2. In section 4.1, "a Middlebox forwards packets from one of > its physical > interfaces to another." I suggest that should refer to logical (IP) > interfaces rather than physical. > In thinking further about the problem we are trying to grapple with, I think we need to have a much wider discusion on the "view" that a MIDCOM Agent can obtain. The issue of interfaces is one aspect of this. For example, MIDCOM is trying to enable an external (from the Middlebox) ALG to be written for a specific protocol or application. However there - and I think we have agreed this (this email is testing for concensus on the email list if not!) - the requirement that the Middlebox can support multiple concurrent MIDCOM Agents. So there is a need for the Middlebox to be able to say to an Agent, here are the things that are appropriate to you (and by the way I'm not telling you what else is going on!). > 3. In section 5.1,it states that "applications may > require... translation > of IP addresses... and knowledge of the specific translations > used". In > fact, applications do not require this and cannot get this > knowledge unless > they happen to be acting as the Midcom Agent. Rather, > operation of the > application through the middlebox may require the translation of IP > addresses etc. And it is the Midcom Agent that may require > knowledge of > the specific translations used. I propose replacing "Applications may > require ..." with "Midcom agents may request...". Yes I agree this area needs revisiting. I'll make a point to have a look at the text and consider your observation appropriately. > > 4. Regarding the agent having knowledge of the specific > translations used, > is there any requirement that the agent be able to *control* the > translations used??? I think in general the middlebox itself > needs to be > in control of allocating any address/port bindings, but are there > applications where multiple packet flows associated with the same > application instance must be assigned the same address, for > the application > to work correctly? If so, the midcom protocol must allow the agent to > request this of the middlebox. > The Agent needs to be able to figure out what the Middlebox has done and is planning to do with packets that travers the Middlebox that are pertinent to the application that the Agent is assisting. > 5. In 5.2.1, 2nd paragraph, it says "The attributes associated with a > Pinhole-Descriptor may be specific to a given Middlebox or > MIDCOM Agent." > Can you please clarify what this means? To what 'attributes' > does this > refer? If it refers to (direction, SA, DA, protocol, SP, DP) > than those > should be specific to an application but not to a given > middlebox or agent! > I believe we were referring to the directionality, source/destination address etc.. I agree that the setting of the attributes are specific to an applications (the data fill). I'll have a look. > 6. Also in 5.2.1, I believe that pinhole specification > should be specified > by "DSCP field" (high 6 bits of the old TOS octet) rather than by the > now-obsolete "TOS field". This is probably also true for IPv6 traffic > class field. > Thanks - I take this on board. > 7. At the end of 5.2.1 it says that the midcom protocol > needs to convey > directives to the middlebox on how to rewrite header fields such as > addresses and port numbers. How is the agent to know what > addresses/ports > may be assigned? Since the agents are distributed I think it > must be the > middlebox that controls the allocation of these. (Perhaps > subject to some > influence from the agent per my comment #4 above.) > I think this comes back to the resource discovery part discussed above. For an Agent to work correctly is needs to know information about the Middlebox to be able to manipulate the packet content correctly (i.e. to handle embedded Source and Destination Addresses etc.). > 8. 5.3.2 Close Pin-Hole. Is it still the intent that only > the agent that > created a pinhole can close it? I recall some discussion > about this on the > list but I don't recall the conclusion. This would be an > impediment to > distributed/redundant agents, but is also a factor in > how/whether pinholes > are timed out. > I don't recall any conclusion to the discussion and have this as an open issue which we need to debate and close (if you will excuse the pun). > 9. Also relative to closing pinholes, if they are not to be > automatically > closed when losing connectivity with the requsting agent, then I think > there should be a mechanism for identifying stale pinhole > identifiers (as > presented by an agent to a middlebox or vice-versa) so that > the devices can > discard requests for actions on those pinholes. This could > be sequence > numbers or qualifying the pinhole identifier with the identity of the > owning Midcom Agent. > I think this needs to be factored into the debate as per your previous comment. If it is possible to leave mases of pin-holes open then we are by definition providing a route for a denial of service attack aren't we? > 10. Section 6.1 seems to embody a different concept of > "registration" than > the framework draft. From my read of the framework, > registration is the > process of configuring a particular agent into either the middlebox or > policy server as an authorized agent. The agent and the > middlebox may then > authenticate each other each time they want to have a session between > themselves. In this requirements draft "registration" seems > to refer to > the mutual authentication. The concepts of registration, > authorization, > authentication, and the middlebox-agent session establishment > need to be > more clearly delineated. > Yes they do. Thanks for spotting this. > 11. Section 7, 7.1.1, 11.2, and 4.1(3rd paragraph) -- is > this all obsolete > text describing diversion of packets to an OOP agent, and > slated for removal? > Yes I think the in-path/out-of-path debate was a red herring. If the MIDCOM Agent is identified as a sub-component of a ALG then the whole debate in this area can be removed since it is then down to the application and the ALG writer to determine how they handle things. > 12. 7.1 "A MIDCOM Agent shall be able to request a pin-hole from a > Middlebox for the purposes of establishing a presence on the external > network." -- I don't understand what is meant by > "establishing a presence > on the external network". Perhaps this should say "... purposes of > allowing communication to or from the external network". > I think this is a throwback to the in-path/out of path debate. > 13. 7.1 "The MIDCOM communication protocol needs to allow > for selective > communication between a specific MIDCOM agent and one or more > Middlebox > functions on the interface to which it is connected." -- why > only "on the > interface to which it is connected"? It seems to me the > pinholes may need > to apply to interfaces other than the one(s) via which the agent > communicates with the middlebox. > Hmmmm - I'll have to look at that. > 14. 10.4, 2nd paragraph: "The MIDCOM Protocol shall describe > the desired > behaviour of the Middlebox for the purposes of a requested > flow(s)." This > paragraph does not seem to belong in this section which is about > authentication requirements. > Hmmmm - I'll have to look at that. > 15. Section 10.5 MIDCOM Policy Requirements. I'm confused by > this section > which discusses a protocol between midcom *agents* and policy > servers. The > framework document discusses communication between the > middlebox and policy > servers but not between the agents and policy servers. And > that protocol > is presumably out of the scope of this document anyway. I > suggest removing > section 10.5. > Hmmmm - I'll have to look at that. > 16. Section 10.7 -- protocol reliability. It is highly desirable for > redundant-hardware implementations that midcom sessions (i.e. > midcom-level > shared state) between an agent and a middlebox be able to > survive restarts > of the transport layer connection. At least, if the > transport layer is TCP > or a protocol that is similarly difficult to support across a > control plane > hardware failover. Work is underway in the IETF to address > this for BGP > and LDP. I think it is also important for midcom. > Yes this is an area where we need to get a better understanding into the document. > 17. In section 12: "Simple Source-address based security is > the least form > of security and should be permitted only to the most trusted > hosts." It > doesn't matter how trusted the hosts are if someone can spoof them. I > propose changing the wording to "... is a minimal form of security and > should be permitted only in the most trusted environments > where those hosts > won't be spoofed." > Or in environments where it isn't important. Yes - good point. > 18. Section 12: "The MIDCOM protocol must enable a trust > relationship to > be established between a specific MIDCOM Agent and a specific > Middlebox for > the purposes of permitting flows between the hosts that flow via the > Middlebox." This is quite confusing, and it only seems to > cover pinholes > not any other middlebox services. I propose changing the > wording to "... > for the purposes of permitting midcom operations to be > performed only in > response to authentic and authorized requests." > I'll look at the text again. > 19. Section 12. through 12.1.2. This whole discussion of trusted and > un-trusted agents is confusing. It seems to state clearly that the > middlebox should only accept requests from trusted agents but > it also talks > about untrusted agents. Is an untrusted agent just one we don't trust > *yet*, or you trying to allow for a sort of "connectionless > trust"? If the > former the wording should be improved. If the latter, I > don't see how this > would work given the requirements (e.g. in section 6.2) to > close pinholes > etc when the relationship (trust?) with the peer goes away. > Overall, the > terms trust and trust relationship are overused in the > industry and poorly > defined. It might be more clear not to use those terms here > at all and > instead talk in terms of authentication and authorization. This area is a bit of a throwback to the charter and I agree it needs some more careful development. > > 20. Section 12.2 item b. "Allow for preservation of the > control messages > once the association has been established." I'm not sure > what preservation > means. Can this be reworded to "Allow for protection of > integrity of the > control messages..."? > Yes this is a difficult area. On the one hand we need to make sure that things don't get out of synch that can't may need to be used in "evidence" of service operation. Conversely I'm aware that this is the "Two Generals and their sub-divisions" problem. I think more debate is needed. > -- Thanks, Mark > > Indeed you are most welcome - thanks for reading the document and providing constructive feedback. regards Richard _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Jul 22 12:44:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13666 for ; Sun, 22 Jul 2001 12:44:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24555; Sun, 22 Jul 2001 12:41:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24527 for ; Sun, 22 Jul 2001 12:41:34 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12780 for ; Sun, 22 Jul 2001 12:40:38 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6MGfE327118 for ; Sun, 22 Jul 2001 09:41:14 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp237.cisco.com [10.21.64.237]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ARG01229; Sun, 22 Jul 2001 09:41:02 -0700 (PDT) Message-Id: <5.1.0.14.0.20010722123200.00a112d0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 22 Jul 2001 12:42:15 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Proposed agenda Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Here's my current version of the agenda for the London meeting. Barring any unforeseen problems the framework document should be through WG last call by then. The bulk of the time will be spent discussing outstanding issues in the requirements document. Please let me know if there's anything else we need to discuss (note that we cannot take meeting time for technology presentations or for material that is outside the current scope of the working group). Also note that a new version of the requirements document will be available before the deadline and the URL in the agenda will be tweaked to reflect that. Thanks, Melinda Middlebox Communication WG (midcom) Friday, August 11 at 0900-1130 ================================== CHAIR: Melinda Shore AGENDA: Agenda bashing, scribe Status Framework document Requirements document Futures DOCUMENTS: http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-03.txt http://www.ietf.org/internet-drafts/draft-ietf-midcom-requirements-01.txt _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Jul 22 15:21:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17135 for ; Sun, 22 Jul 2001 15:21:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27472; Sun, 22 Jul 2001 15:21:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27443 for ; Sun, 22 Jul 2001 15:21:27 -0400 (EDT) Received: from web13807.mail.yahoo.com (web13807.mail.yahoo.com [216.136.175.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16986 for ; Sun, 22 Jul 2001 15:20:31 -0400 (EDT) Message-ID: <20010722192129.60728.qmail@web13807.mail.yahoo.com> Received: from [65.12.33.187] by web13807.mail.yahoo.com via HTTP; Sun, 22 Jul 2001 12:21:29 PDT Date: Sun, 22 Jul 2001 12:21:29 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Framework last call To: Mark Duffy , midcom@ietf.org In-Reply-To: <3.0.5.32.20010720153341.0085e990@10.1.1.249> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Thanks, Mark, for your detailed comments. I appreciate the feedback. Please see my responses below. regards, suresh --- Mark Duffy wrote: > Hi, I have some comments and suggestions on > draft-ietf-midcom-framework-03.txt. > > . The document should make a clear statement on what in a packet the > middlebox is expected to understand and be able to classify on. I hope > this is only IP header fields and TCP/UDP port numbers. (Thus the > middlebox would be "IP-aware" and "TCP/UDP-aware" but not > "application-aware".) There was the long discussion on the maiiling list > about being BEEP-aware but I'm not sure what the consensus was (if any). > Application intelligence goes beyond just the TCP/UDP payload. It includes correlation between sessions, session orientations, port usage and so forth. The document states in no uncertain terms that the MIDCOM protocol allows the middlebox to move application intelligence to agents (Ex: refer the text in sections 2.10 and 4). I dont believe it is necessary to single out TCP/UDP payload. > . The document should make a clear statement on what in a packet the > middlebox may modify. My understanding is this should be only the IP > header and TCP/UDP port numbers (and associated checksums). The > requirements draft states this in section 4.1 although it is vague about > what constitutes the "packet header". My understanding is only the Midcom > Agent should modify any higher layer information. > Same as above. > . In section 1. Introduction, 1st paragraph, it says "The discussion scope > of this document is however limited to middleboxes implementing Firewall > and NAT services only." This improperly (I believe) excludes middleboxes > implementing other services but doing so outside of the midcom framework. > I suggest rewording this as "The discussion scope of this document is > however limited to firewall and NAT middlebox services." > OK. > . In 2.1 it says "A middlebox function or a middlebox service is an > operation or method performed by a network intermediary that requires > application specific intelligence for its operation." I propose replacing > "requires application specific intelligence" with "may require application > specific intelligence". For example, if a firewall device were set up to > pass all TCP packets but drop all non-TCP packets, that would not require > application specific intelligence. Would it not however still be > considered a middlebox function? I guess, you are saying that you cannot call something "a middlebox" by the way it is configured at a given time. Good point. I will fix the definition as you suggest. > > . 2.4 -- NAT. "Network Address Translation is a method by which IP > addresses are mapped from one address realm ..." I suggest this should > mention port numbers as well i.e. "Network Address Translation is a method > by which IP addresses and TCP/UDP port numbers are mapped ..." > No problem. I will add the following at the end of first pragraph. Two types of NAT are most common. Basic-NAT, where only an IP address (and the related IP, TCP/UDP checksums) of packets is altered and NAPT (Network Address Port Translation), where both an IP address and a transport layer identifier, such as a TCP/UDP port (and the related IP, TCP/UDP checksums) are altered. > . In 3.0 beneath the figure it introduces the concept of SessionDirection. > The implication I get is that this identifies either "outbound" or > "inbound". This may become limiting. For example, in a service provider > based middlebox there may be "in" sides associated with each customer of > the provider. While this could be modeled as many logical middleboxes each > with an inside and outside, it would be much more flexible for the midcom > architecture to provide for this. One way to do this would be to enlarge > the Session-Descriptor tuple to also specify the applicable interface. > Another way would be to allow for specifying in the tuple which realms the > packet is moving from and to (although I don't know of any existing way to > name and refer to these realms). (Section 8.1 relates to this somewhat.) > All parameters of the tuple, including SessionDirection, are with reference to an interface on the middlebox. I will state this explicitly. Thanks. > . In 3.0 below the figure it states "The attributes associated with a > Session-Descriptor may be specific to the individual middlebox function." > Can you please clarify the meaning of this? What *are* the "attributes"? > Are they the what-to-do-when-a-packet-matches-this-session-descriptor stuff? > Yes - a variety of Timers, NAT translation parameters etc. Will inlude the examples. > . In 5.0 it states "In-Path MIDCOM agents are entities that have a native > role in the path of the application traversal ... idependent of their > MIDCOM function." Why must they have a native role? This would pretty > much eliminate using midcom for any applications that don't already employ > such devices. I don't see any reason to exclude agent devices placed there > solely for the purpose of being an in-path Midcom Agent. I propose we > revise that sentence to read: "In-Path MIDCOM agents are MIDCOM agents that > are located naturally within the message path of the application they are > associated with." Or strike the sentence entirely since this is just > repeating the definition presented in section 2.8. > You are right about the interpretation of the definition. That was the intention. What non-native kind did you have in mind? > . In the last paragraph on Page 10 (section 5.0) it uses the words > interjecting/interjected. Those should be replaced by > intercepting/intercepted. (It is talking here about the agent receiving > and manipulating packets already in-flight, not about introducing new > packets.) > Interception refers to processing packets in-flight not targeted to itself. That is not the case with proxies. The packets are targeted to/from the proxy server. So, I believe, the existing wording is the right choice. > . In section 6.1: "Simple Source-address based security is the least form > of security in a trusted domain and may be permitted to trusted hosts." It > doesn't matter how trusted the hosts are if someone can spoof them! I > propose changing the wording to "Simple Source-address based security is a > minimal form of security and should be relied on only in the most trusted > environments where those hosts won't be spoofed." > OK. > . Section 6.2 -- registration. It is not clear what "registration" means > in the midcom context and I think this should be clarified in the document. > By my read it refers to configuring information about the agent into the > middlebox or entering similar information into the policy server(s). If > this is what it means than this is probably something done *on behalf of > the agent* by some operator, rather than *by the agent itself*. Yes, this is what is meant. I will reword the text to get this message across. > If this is > the case it doesn't make sense to me that the agent would "deregister" > itself as described in the last paragraph of 6.2 -- that seems to relate to > breaking the current session. > Oops.. wrong choice of word. Will replace the word "deregister" with "disconnect". Thanks for pointing out. > We need to define "registration" and how it relates to one or the other of > - provisioning of authorization information, or > - establishment of an authenticated session between an authorized agent > and a middlebox. > It is the former. I believe, the following rewording in the first paragraph of section 6.2 would make this clear. Prior to giving MIDCOM agents access to the middlebox resources, a registration process MUST take place. Registration is a different process than establishing a transport connection. The former requires exchanging agent profile information with the middlebox or a policy server(s). Agent registration is often a manual operation performed by an opertor rather than the agent itself. The latter refers to establishing a MIDCOM transport connection and exchanging security credentials between an agent and a middlebox. The latter uses the information from the former for connection establishment. > Section 6.2, "Coupling MIDCOM agents with the middlebox resources requires > a means of reflecting that into the resource description table of the > middlebox. In the case of a firewall, for example, the ACL tuple may be > altered to reflect the optional ALG presence. The revised ACL may look > something like the following. > (, , , > , , , ) > Can you please clarify this? Aside from the that tuple appears to be > a specification for identifying a set of packets. I don't see what an ALG > has to do with that. Besides, isn't it a fundamental concept of midcom > that the ALG belongs in the agent, not in the middlebox? > This is what registration of an agent/ALG with the middlebox looks like. > . Section 8.4 -- timers: "However, the middlebox should be able to recover > the dynamically allocated resources even as the agent that was responsible > for the allocation is not alive." Does that mean "recover even while > still alive" or "recover when not alive"? > Recovering when the agent is alive happens by design, when the dynamically allocated resources are no longer required. > . Separate from any timers on individual resources, there should be a way > to detect disappearance of the agent. That disappearance should perhaps > free all the related resources as stated in > draft-ietf-midcom-requirements-01 section 5.3.2. (Or was there a decision > on the mailing list that disappearance of the Agent not cause all its > allocated resources to be immediately freed?) Why should the middlebox > time out allocated resources while the session with the agent is still > alive? But if it does so, it should notify the agent! > This is so the middlebox is not exhausted of its resources when an agent dies on it. > . Section 8.5: " In the case of a middlebox implementing NAT and firewall > services, it is safe to state that the NAT operation will precede firewall > on the egress and will follow firewall on the ingress." From what frame > of reference are we defining egress and ingress? Please clarify. OK. Hope the following replacement will work for you. Ingress and egress are with reference to an interface. In the case of a middlebox implementing NAT and firewall services, it is safe to state that the NAT operation on an interface will precede firewall on the egress and will follow firewall on the ingress. > If this > is egress from and ingress to the private domain, then I disagree with this > statement. I believe the firewall rules must be based on the private > addresses etc. (which are fixed and known), not on the public addresses > (which are dynamically assigned). In fact I believe this is what the next > sentence in 8.5 means: "Further, firewall access control lists used by a > firewall are assumed to be based on session parameters as seen on the > interface supporting firewall service." > Hope the above replacement text clarifies this. > . There is no section between 9 and 11. > Got it. Will renumber. thanks. > . Section 12 -- security considerations: "The premise of middlebox > operation fundamentally requires the data to be in the clear as the > middlebox needs the ability to inspect and/or modify packet headers and > payload." I believe what you are referring to here is a pre-midcom world, > as contrasted by the next paragraph. It would help to state here > explicitly that this refers to the world without midcom. > OK. > . Section 12, last paragraph on Page 32: " A middlebox service may be > abruptly disrupted due to malicious manipulation or incorrect > implementation of the middlebox or its agents of a certain shared resource > by an agent purporting to offer ALG service for a different middlebox > function." This is very hard to understand. For me anyway :-) Here is a > suggested rewording: "A middlebox service may be disrupted due to > conflicting directives from multiple agents associated with different > middlebox functions but applied to the same application session." > You are right. I do like your wording better. Thanks. > -- Thanks, Mark > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom ===== __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Jul 22 21:32:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15898 for ; Sun, 22 Jul 2001 21:32:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03316; Sun, 22 Jul 2001 21:23:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03285 for ; Sun, 22 Jul 2001 21:23:36 -0400 (EDT) Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15758 for ; Sun, 22 Jul 2001 21:22:38 -0400 (EDT) From: richard.swale@bt.com Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Mon, 23 Jul 2001 02:22:35 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Mon, 23 Jul 2001 02:22:03 +0100 Message-ID: To: midcom@ietf.org Date: Mon, 23 Jul 2001 02:21:52 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Subject: [midcom] Comments on Framework 03 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 Hi, I have a number of comments on the 03 draft. 1. The In-path and out-of-path issue doesn't seem to have closed and there is plenty of reference to it in the document. I have been thinking about the view the protocol gets and it seems to be easier to position the protocol as flowing between a middlebox and an Agent only - as per the text in some places. The in-path and out-of -path issue then only becomes part of the debate if the actual MIDCOM Agent is interpreted to be the whole ALG function - which the document does in some places. If on the other hand, the MIDCOM Agent is considered to be only that part of an ALG that talks to the Middlebox from a control point of view, then the whole in-path and out -of-path debate disappears. i.e. +--------------+ +--------------------+ | ALG | | ALG | +--------------+ | +---------+ | | MCA | | | MCA | | | | | | | | + -------------+ +---+----------+----+ ^ ^ | | v v +------------------+ +------------------+ | MIddlebox | | Middlebox | +-------------------+ +------------------+ Where MCA is the MIDCOM Agent. In the second case, the ALG would use the MIDCOM Agent to route the session control streams (e.g. SIP messages) to the ALG on another logical interface to the ALG as opposed to coming through the Agent. If this is the case then whether the function the agent is part of (i.e. the bigger ALG function) sits in the signalling path or not becomes irelevant. So from this point of view I think it may be better to position the MIDCOM Agent as purely being that part of a bigger function which communicate with the Middlebox for command and control purposes. If this approach is agreeable, then the discussion concerning in-path and out-of-path can come out of the document. Section 4 seems to have lots of embedded requirements concerning the protocol. Is this the right place to put this stuff? I would suggest possibly not. Section 5 seems to have a lot of common text with section 2.8. Could these be merged? Section 6.1 seems to have a lot of embedded requirements Section 6.2 also seems to have a lot of embedded requirements Section 8.2 seems to repeat section 4 and section 6.2. nits === Page 1 and elsewhere. NetMeeting V3.x isn't always a peer-peer application so it is a bit misleading to cite it. It can be - but not always. I think the term "Message Sequence" might read a bit better than "Timeline Flow" in section 7 Section 8.6 makes reference to Q.931 which technically isn't correct and should probably read H.225.0 call signalling. Hope this helps. regards Richard _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 23 09:10:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17884 for ; Mon, 23 Jul 2001 09:10:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26749; Mon, 23 Jul 2001 09:07:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26723 for ; Mon, 23 Jul 2001 09:07:56 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17626 for ; Mon, 23 Jul 2001 09:07:01 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6ND7W306715; Mon, 23 Jul 2001 06:07:32 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn2-132.cisco.com [10.21.112.132]) by airborne.cisco.com (Mirapoint) with ESMTP id AHM00490; Mon, 23 Jul 2001 06:07:20 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.94 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15196.8583.170000.302982@gargle.gargle.HOWL> Date: Mon, 23 Jul 2001 09:07:19 -0400 To: Paul Sijben Cc: Melinda Shore , midcom@ietf.org Subject: Re: [midcom] Framework last call In-Reply-To: <3B5C1F9E.6357D754@lucent.com> References: <5.1.0.14.0.20010720131633.00a672d0@mira-sjc5-4.cisco.com> <3B5C1F9E.6357D754@lucent.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Paul, could you list (at least some of) the implicit requirements you see in the framework document, so we know what to clean up? _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 23 09:10:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17903 for ; Mon, 23 Jul 2001 09:10:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26215; Mon, 23 Jul 2001 08:58:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26186 for ; Mon, 23 Jul 2001 08:58:40 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17042 for ; Mon, 23 Jul 2001 08:57:46 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6NCwfw08347 for ; Mon, 23 Jul 2001 08:58:41 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA04443; Mon, 23 Jul 2001 14:58:39 +0200 (MET DST) Cc: midcom@ietf.org Received: from hzsgg01.nl.lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA04438; Mon, 23 Jul 2001 14:58:38 +0200 (MET DST) Received: from lucent.com by hzsgg01.nl.lucent.com (8.8.8+Sun/EMS-1.4.1 client sol2) id OAA03367; Mon, 23 Jul 2001 14:58:38 +0200 (MET DST) Message-ID: <3B5C1F9E.6357D754@lucent.com> Date: Mon, 23 Jul 2001 14:59:10 +0200 From: Paul Sijben Organization: Lucent technologies, The Netherlands X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Melinda Shore Original-CC: midcom@ietf.org Subject: Re: [midcom] Framework last call References: <5.1.0.14.0.20010720131633.00a672d0@mira-sjc5-4.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I am sorry but I do not believe that the framework doc is ready for last call. Just as people have (rightly) criticized that the requirements doc overlaps with the framework doc and hence needs some stuff removed, the same is true the other way around. The framework document contains a lot of explicit and implicit protocol requirements that need to be removed from that draft and considered if they are present in the requirements document. If they are not there, they need to be discussed. Also the document seems to be so verbose that I find it difficult to read (as in; find the midcom specific material amidst the generic tutorial). I would propose we bring both the output documents of this WG in better shape and approve them together so they are in alignment. Paul Melinda Shore wrote: > > The midcom framework document (available as > http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-03.txt > is ready for working group last call. Last call closes Friday, 3 > August 2001. Please send all comments to the midcom mailing list. > > Thanks, > > Melinda > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom -- Paul Sijben Tel:+31 356874774 Lucent Technologies Fax:+31 356875954 Forward Looking Work Huizen, The Netherlands http://voip.nl.lucent.com/~sijben (internal) _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 23 09:21:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18702 for ; Mon, 23 Jul 2001 09:21:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27171; Mon, 23 Jul 2001 09:20:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27142 for ; Mon, 23 Jul 2001 09:20:02 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18523 for ; Mon, 23 Jul 2001 09:19:00 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6NDJb316447; Mon, 23 Jul 2001 06:19:37 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-344.cisco.com [10.21.65.88]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ARI02994; Mon, 23 Jul 2001 06:19:25 -0700 (PDT) Message-Id: <5.1.0.14.0.20010723091826.00a09d90@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 23 Jul 2001 09:20:40 -0400 To: Paul Sijben From: Melinda Shore Subject: Re: [midcom] Framework last call Cc: midcom@ietf.org In-Reply-To: <3B5C1F9E.6357D754@lucent.com> References: <5.1.0.14.0.20010720131633.00a672d0@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 02:59 PM 7/23/01 +0200, Paul Sijben wrote: >The framework document contains a lot of explicit and implicit protocol >requirements that need to be removed from that draft and considered if >they are present in the requirements document. If they are not there, they >need to be discussed. It would be a huge help in knowing how to proceed if you could be more specific in what you'd like to see changed/ removed. Last call is a time for specific, substantive objections. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 23 15:23:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17740 for ; Mon, 23 Jul 2001 15:23:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09483; Mon, 23 Jul 2001 14:58:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09454 for ; Mon, 23 Jul 2001 14:58:05 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15976 for ; Mon, 23 Jul 2001 14:57:10 -0400 (EDT) Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PDZ556J0; Mon, 23 Jul 2001 14:57:37 -0400 Message-Id: <3.0.5.32.20010723145327.00863320@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 23 Jul 2001 14:53:27 -0400 To: Pyda Srisuresh , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Framework last call -- level of middlebox intelligence In-Reply-To: <20010722192129.60728.qmail@web13807.mail.yahoo.com> References: <3.0.5.32.20010720153341.0085e990@10.1.1.249> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi Suresh and thanks for your response! I have another round of questions on a few of the issues. I'll put them into separate emails. Here's the first. >> [Mark wrote] >> . The document should make a clear statement on what in a packet the >> middlebox is expected to understand and be able to classify on. I hope >> this is only IP header fields and TCP/UDP port numbers. (Thus the >> middlebox would be "IP-aware" and "TCP/UDP-aware" but not >> "application-aware".) There was the long discussion on the maiiling list >> about being BEEP-aware but I'm not sure what the consensus was (if any). > [Suresh replied] >Application intelligence goes beyond just the TCP/UDP payload. It includes >correlation between sessions, session orientations, port usage and so >forth. The document states in no uncertain terms that the MIDCOM protocol >allows the middlebox to move application intelligence to agents (Ex: refer >the text in sections 2.10 and 4). I dont believe it is necessary to >single out TCP/UDP payload. I think I did not state my point clearly enough. Let me try again. Yes, the document is quite clear that the application intelligence is to be in the agents. What I would like to get clarified is exactly how much "intelligence" needs to remain in the middlebox after that "application" intelligence is moved out. This is fundamentally about where we are drawing the line between the application and the network. It seems clear that the middlebox must be aware of TCP and UDP ports, so that the agent may direct it to give particular treatment (pinholes, NAT translations, etc.) for traffic on particular TCP/UDP ports. For example, the Session-descriptor is described as consisting of direction, source/destination addresses, IP protocol, and source/destination ports. And in section 4 it mentions "port based sessions". Yet there has been discussion on the list (e.g. the recent thread about BEEP) that the middlebox might be expected to look deeper into the packet and give separate treatment to separate threads multiplexed into one port. I am not sure what the consensus was on that. My personal opinion is that the midcom protocol should not ask of the middlebox to look into anything other than the IP, tcp, and udp headers. But in any event we should all come to some agreement on this and place text in the framework document that clearly states the agreed direction. >> [Mark wrote] >> . The document should make a clear statement on what in a packet the >> middlebox may modify. My understanding is this should be only the IP >> header and TCP/UDP port numbers (and associated checksums). The >> requirements draft states this in section 4.1 although it is vague about >> what constitutes the "packet header". My understanding is only the Midcom >> Agent should modify any higher layer information. > [Suresh replied] >Same as above. This is closely related to the issue above. While the above discussion is about what fields the middlebox should be *looking at* to make its decision about a packet, this part of the question is about what fields the middlebox might be expected to modify in processing the packet. Again my personal opinion is that this should be limited to fields within the IP, TCP, and UDP headers but in any event the WG consensus on this should be clearly stated in the framework. -- Thanks, Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 23 15:39:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18705 for ; Mon, 23 Jul 2001 15:39:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10119; Mon, 23 Jul 2001 15:21:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10089 for ; Mon, 23 Jul 2001 15:21:00 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17547 for ; Mon, 23 Jul 2001 15:20:03 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6NJKgT10851 for ; Mon, 23 Jul 2001 12:20:42 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn2-132.cisco.com [10.21.112.132]) by airborne.cisco.com (Mirapoint) with ESMTP id AHO03706; Mon, 23 Jul 2001 12:20:28 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.94 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15196.30969.360000.269188@gargle.gargle.HOWL> Date: Mon, 23 Jul 2001 15:20:25 -0400 To: midcom@ietf.org Subject: Re: [midcom] Framework last call -- level of middlebox intelligence In-Reply-To: <3.0.5.32.20010723145327.00863320@10.1.1.249> References: <3.0.5.32.20010720153341.0085e990@10.1.1.249> <3.0.5.32.20010723145327.00863320@10.1.1.249> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit On 23 Jul 2001 at 14:53 -0400, Mark Duffy apparently wrote: > Yes, the document is quite clear that the application intelligence is to be > in the agents. What I would like to get clarified is exactly how much > "intelligence" needs to remain in the middlebox after that "application" > intelligence is moved out. What are your requirements? Why? _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 23 15:41:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18791 for ; Mon, 23 Jul 2001 15:41:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10283; Mon, 23 Jul 2001 15:26:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10250 for ; Mon, 23 Jul 2001 15:26:36 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17865 for ; Mon, 23 Jul 2001 15:25:40 -0400 (EDT) Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PDZ556N9; Mon, 23 Jul 2001 15:26:08 -0400 Message-Id: <3.0.5.32.20010723152522.0093f100@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 23 Jul 2001 15:25:22 -0400 To: Pyda Srisuresh , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Framework last call -- middlebox data model In-Reply-To: <20010722192129.60728.qmail@web13807.mail.yahoo.com> References: <3.0.5.32.20010720153341.0085e990@10.1.1.249> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi Suresh and all, >> [Mark] >> . In 3.0 below the figure it states "The attributes associated with a >> Session-Descriptor may be specific to the individual middlebox function." >> Can you please clarify the meaning of this? What *are* the "attributes"? >> Are they the what-to-do-when-a-packet-matches-this-session-descriptor stuff? >> > [Suresh] >Yes - a variety of Timers, NAT translation parameters etc. Will inlude the >examples. > >> [Mark] >> Section 6.2, "Coupling MIDCOM agents with the middlebox resources requires >> a means of reflecting that into the resource description table of the >> middlebox. In the case of a firewall, for example, the ACL tuple may be >> altered to reflect the optional ALG presence. The revised ACL may look >> something like the following. >> (, , , >> , , , ) >> Can you please clarify this? Aside from the that tuple appears to be >> a specification for identifying a set of packets. I don't see what an ALG >> has to do with that. Besides, isn't it a fundamental concept of midcom >> that the ALG belongs in the agent, not in the middlebox? >> > [Suresh] >This is what registration of an agent/ALG with the middlebox looks like. Let me test my understanding of this. The middlebox maintains a number of "session-descriptors" each of which describes a set of packets that are to be treated in a particular way. The session-descriptor is a tuple roughly of the form (Interface, SessionDirection, SourceAddress, DestinationAddress, Protocol, SourcePort, DestinationPort). Each session descriptor has associated with it some number of actions to be performed by the middlebox. So far there doesn't seem to be a midcom term for these. Let me call them session-actions. I would suppose these actions are things like "open a firewall pinhole", "apply NAT translation y", and perhaps in the future "mark Diffserv codepoint value z". I would further suppose that each session-action has associated with it a timer (possibly) and an identifier of the particular Agent that requested that action. If this view of the world is consistent with that of others in the wg, I would suggest that describing the middlebox function in terms of an abstract data model like that would help to clarify the framework. I'd be willing to propose some text if there is interest in this. --Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 23 17:16:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24421 for ; Mon, 23 Jul 2001 17:16:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13492; Mon, 23 Jul 2001 16:55:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13465 for ; Mon, 23 Jul 2001 16:55:11 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22969 for ; Mon, 23 Jul 2001 16:54:16 -0400 (EDT) Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PDZ556VR; Mon, 23 Jul 2001 16:54:45 -0400 Message-Id: <3.0.5.32.20010723165306.00961450@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 23 Jul 2001 16:53:06 -0400 To: "Scott Brim" , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Framework last call -- level of middlebox intelligence In-Reply-To: <15196.30969.360000.269188@gargle.gargle.HOWL> References: <3.0.5.32.20010723145327.00863320@10.1.1.249> <3.0.5.32.20010720153341.0085e990@10.1.1.249> <3.0.5.32.20010723145327.00863320@10.1.1.249> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 03:20 PM 7/23/01 -0400, Scott Brim wrote: >On 23 Jul 2001 at 14:53 -0400, Mark Duffy apparently wrote: >> Yes, the document is quite clear that the application intelligence is to be >> in the agents. What I would like to get clarified is exactly how much >> "intelligence" needs to remain in the middlebox after that "application" >> intelligence is moved out. > >What are your requirements? Why? Scott, I'm not sure I understand your question. My message was not about adding any requirements on midcom, if perchance that's what you are asking. The agents will use the midcom protocol to tell middleboxes to do particular things to/for particular packets. As asked in detail in the rest of my posting of which you quote a part, I am looking for clarification (in the framework document) as to how deep in the packet the middlebox is expected to examine and what protocol headers the middlebox is expected to understand. Why am I looking for this? Because without stating this we in fact have very little. It doesn't mean much to say midcom allows moving the "application" intelligence from the middlebox to the midcom agent if one does not define where the "applications" begin. No? -Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 23 17: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 SMTP id RAA25936 for ; Mon, 23 Jul 2001 17:39:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14332; Mon, 23 Jul 2001 17:20:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14301 for ; Mon, 23 Jul 2001 17:20:57 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24587 for ; Mon, 23 Jul 2001 17:20:02 -0400 (EDT) Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PDZ556X3; Mon, 23 Jul 2001 17:20:29 -0400 Message-Id: <3.0.5.32.20010723171951.009935f0@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 23 Jul 2001 17:19:51 -0400 To: Pyda Srisuresh , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Framework last call -- nonnative agents In-Reply-To: <20010722192129.60728.qmail@web13807.mail.yahoo.com> References: <3.0.5.32.20010720153341.0085e990@10.1.1.249> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Suresh, see below... >> [Mark] >> . In 5.0 it states "In-Path MIDCOM agents are entities that have a native >> role in the path of the application traversal ... idependent of their >> MIDCOM function." Why must they have a native role? This would pretty >> much eliminate using midcom for any applications that don't already employ >> such devices. I don't see any reason to exclude agent devices placed there >> solely for the purpose of being an in-path Midcom Agent. I propose we >> revise that sentence to read: "In-Path MIDCOM agents are MIDCOM agents that >> are located naturally within the message path of the application they are >> associated with." Or strike the sentence entirely since this is just >> repeating the definition presented in section 2.8. >> > {Suresh] >You are right about the interpretation of the definition. That was the >intention. What non-native kind did you have in mind? I don't have any specific kind in mind but let's use ftp as an example. For the sake of the example suppose that ftp proxies will not be used. Passing ftp through a NAT box requires an ftp-aware ALG function to modify data on the ftp control session. Today this ALG would perhaps be a component of the NAT middlebox. In the spirit of midcom, I would like to leave open the possibility to remove the ftp application intelligence from the middlebox and deploy it instead in a Midcom Agent. Since there is not necessarily any ftp-aware box already in the network (excepting the end points) we might want to deploy an ftp-aware midcom agent device expressly for the purpose of controlling the non-ftp-aware middlebox. This device would not have a native role in the path of the application traversal idependent of the MIDCOM function, but I don't see why it should therefore be excluded by the midcom framework. In other words, why should midcom care what (if anything) else the agent device does outside of its midcom role? --Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 23 17:39:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25957 for ; Mon, 23 Jul 2001 17:39:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14133; Mon, 23 Jul 2001 17:16:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14102 for ; Mon, 23 Jul 2001 17:16:07 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24358 for ; Mon, 23 Jul 2001 17:15:12 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6NL7hi04007; Mon, 23 Jul 2001 14:13:13 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn2-132.cisco.com [10.21.112.132]) by airborne.cisco.com (Mirapoint) with ESMTP id AHP01213; Mon, 23 Jul 2001 14:09:26 -0700 (PDT) X-Mailer: emacs 20.7.1 (via feedmail 9-beta-12 I); VM 6.94 under Emacs 20.7.1 From: "Scott Brim" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15196.37506.780000.664563@gargle.gargle.HOWL> Date: Mon, 23 Jul 2001 17:09:22 -0400 To: Mark Duffy Cc: midcom@ietf.org Subject: Re: [midcom] Framework last call -- level of middlebox intelligence In-Reply-To: <3.0.5.32.20010723165306.00961450@10.1.1.249> References: <3.0.5.32.20010723145327.00863320@10.1.1.249> <3.0.5.32.20010720153341.0085e990@10.1.1.249> <3.0.5.32.20010723165306.00961450@10.1.1.249> 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 Mark. More detail ... That's exactly my point. You're asking "how deep in the packet should a middlebox look", and my answer is "as deep as it has to". How deep is that? That depends on what the requirements are. If nobody has a need for a middlebox to look deeper than the IP header, then we can stop there. So, what needs do you personally see? Do you see any reason to go deeper? If so, we can include your requirements, and justifications for them, in the requirements draft. "What are your requirements" was meant to be shorthand for all that. ...Scott On 23 Jul 2001 at 16:53 -0400, Mark Duffy apparently wrote: > At 03:20 PM 7/23/01 -0400, Scott Brim wrote: > >On 23 Jul 2001 at 14:53 -0400, Mark Duffy apparently wrote: > >> Yes, the document is quite clear that the application intelligence is to be > >> in the agents. What I would like to get clarified is exactly how much > >> "intelligence" needs to remain in the middlebox after that "application" > >> intelligence is moved out. > > > >What are your requirements? Why? > > Scott, I'm not sure I understand your question. > My message was not about adding any requirements on midcom, if perchance > that's what you are asking. > > The agents will use the midcom protocol to tell middleboxes to do > particular things to/for particular packets. As asked in detail in the > rest of my posting of which you quote a part, I am looking for > clarification (in the framework document) as to how deep in the packet the > middlebox is expected to examine and what protocol headers the middlebox is > expected to understand. > > Why am I looking for this? Because without stating this we in fact have > very little. It doesn't mean much to say midcom allows moving the > "application" intelligence from the middlebox to the midcom agent if one > does not define where the "applications" begin. No? > > -Mark > > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 23 18:05:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27165 for ; Mon, 23 Jul 2001 18:05:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15175; Mon, 23 Jul 2001 17:48:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15145 for ; Mon, 23 Jul 2001 17:48:28 -0400 (EDT) Received: from gollum.axion.bt.co.uk (gollum.axion.bt.co.uk [132.146.17.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26458 for ; Mon, 23 Jul 2001 17:47:32 -0400 (EDT) From: richard.swale@bt.com Received: from cbtlipnt01.btlabs.bt.co.uk by gollum (local) with ESMTP; Mon, 23 Jul 2001 22:46:36 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Mon, 23 Jul 2001 22:46:36 +0100 Message-ID: To: midcom@ietf.org, srisuresh@yahoo.com Date: Mon, 23 Jul 2001 22:45:50 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Subject: [midcom] comments and nits on framework-03 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org suresh, please find below my comments and nits list concerning the 03 framework draft. I think the major issues are the inclusion and handling of the scenarios in the document and also the relationship between the scope of the MIDCOM Agent and the ALG which may help us punt the in-path out-of-path issue once and for all. regards Richard ======== page 1 - NetMeeting v3.x doesn't necessarily fall under the class of peer-peer applications as it can work with an H.323 gatekeeper. Perhaps this reference should be moved elsewhere in the text or dropped. page 2 - last sentence prior to section 1: ...complex applications to operate correctly ..... page 2 - section 1 first paragraph: provides routing transparency across indirection between page 2 - section 1 first paragraph: (ALGs) are may be page 2 - section 1 first paragraph: ...payload so in order that the... page 2 - section 1 first paragraph last sentence: deployment of new services applications page 2 - section 1 second paragraph last sentence: ... degrade in performance. page 2 - section 1 third paragraph: can be safely removed from.... page 3 - section 1 last paragraph: The remaining sections cover the..... suggested replacement text "The remaining sections cover the components of the framework, illustrations of the MIDCOM approach using example flows and a consideration of operational issues." page 3 - section 1 last paragraph: ... SIP flows using the MIDCOM framework in which the a MIDCOM Agent is co-resident on a with a SIP proxy server. page 3 - section 2.1: .....network intermediary element that requires...... page 3 - section 2.1: Policy based packet... suggested replacement text "Examples of middlebox functionality include policy based packet filtering (a.k.a. firewalling), Network Address Translation (NAT), intrustion detection, load balancing, policy based tunnelling and IPsec security." page 4 - section 2.2: A middlebox is a network intermediary device that implements one or more of the middlebox services. For example, a NAT middlebox is a middlebox implementing NAT service. implements NAT services and a firewall is a middlebox which implements policy based packet filtering services. A firewall middlebox is a middlebox implementing firewall service. page 4 - section 2.3: rephrase to read "A firewall is a policy based packet filtering middlebox function, typically used for resticting access to or from specific devices and applications. The policies used to control a firewall are often termed Access Control Lists (ACLs). page 5 - section 2.6. I would like to suggest we clarify the difference between an ALG and a MIDCOM Agent. If we declare a MIDCOM Agent to be only that functionality that makes requirests of a Middlebox to gain acess to its resources and an ALG an entity which embodies application specific functionality that enables a given application to function correctly in the presence of a given middlebix device. Then the MIDCOM Agent _may_ be a constituent element of an ALG (and will be if the ALG is using the MIDCOM approach). This more importantly then means that the issue of in-path and out-of-path instantly becomes irrelevant as the application messages don't go to the MIDCOM Agent (which is clearly the case since the MIDCOM protocol is only asking for pin-holes to be openned and closed and not directly involved in the processing of the application messages). page 5 and page 6 - section 2.8: all of the discussion concerning in-path and out-of-path MIDCOM Agents can be deleted based upon the above observation. page 6 - section 2.9: A Policy Server is a management.... page 6 - section 2.9 last paragraph:and the policy interface between.... page 6 - section 2.9 last paragraph: is out of bounds the scope of for this document. page 6 - section 2.9 last paragraph a corporate domain is an instance of an adminstrative domain: (or corporate) page 6 - section 2.9 last paragraph, next to last sentence: suggested replacement text "As befitting any end user application, this type of application specfic policy data is outside of the scope of the Policy Server considered in this document." page 8 - figure 1: the MIDCOM Agent co-resident on Proxy Server is a duplication (an possibly confusing one!) with the MIDCOM Agent on Appl GW. This is really the same thing - and certainly is if the discussion of section 2.6 is concluded. page 8 - section 3.0: The paragraph "Firewall ACLs, NAT-BINDs..." effectively embeds implementation without a discussion of requirements. Suggest this paragraph is deleted and figure 1 modified accordlingly as it prejudices requirements. page 9 - section 4: This section describes the behaviour of the MIDCOM protocol and embeds assumed requirements throughout. Suggest this section is deleted. page 10 - section 5.0: This section repeates the discussion of in-path and out-of-path MIDCOM Agents. Suggest this section is deleted and replaced by incorporated text from Christian's scenarios draft as per the suggestion in my email to the MIDCOM list of 25th June. page 13 - section 6.1: This contains a list of assumptions and a mixture of requirements "... the middlebox MUST not process...." which duplicate a discussion of requirements in the requirements document and should therefore be removed from this document. page 14 - section 6.2: This section contains another string of requirements concerning the protocol such as "... registration process MUST take place...". This should be handled as per section 6.1. page 16 - section 7.0: depending upon the outcome concerning section 2.8 and 4, section 7 can be retitled simply "Illustration of the MIDCOM Framework". page 17 - section 7.0 last paragraph on the page: this contains a lot of assumptions concerning the requirements of the MIDCOM protocol concerning the use of timers. These parts of the paragraph should be removed from this document. page 18 - section 7.0 first paragraph on the page: ... stream through. The Policy Server is also omitted from figure 3 and the associated message sequence charts not shown in the diagram below or on the timelines for the same reason. {I think the term message sequence chart is both more technically accurate and descriptive of the diagrams since this is a more widely understood term and there is no calibrated time scale on them in anycase.} page 18 - section 7.0 last paragraph: typical message timeline sequence for of operations that may occur between the various elements involved when establishing a simple telephone call using SIP. transpire with the various elements involved in a SIP telephony application path. page 18 - section 7.1, retitle depending upon the outcome of the comments above. page 19 - section 7.2, retitle as per section 7.1 page 23 - section 7.3, retitle as per section 7.1 page 27 - section 8.2, this is a repeat of the issue concerning sections 4 and 6.2. page 27 - section 8.3 is a requirement and should be deleted from this document. page 27 - section 8.4 is conjecture concerning assumed requirements and should be deleed from this document. page 28 - section 8.6 forth from last paragraph refers to Q.931. This is not correct in this context and should refer to the H.225.0 call signalling protocol. page 28 - section 8.6 second to last paragraph seems to be repetative and redundant. Suggest it is deleted. page 29 - section 9: I have heard the term "Bastion Host" used in this context and am open to comment as to whether this is preferable to DMZ host. page 31 - section 12 paragraph 3: this seems to be a tutorial. Is it necessary here? page 32 - section 12: there is a mixture of tutorial information, discussion and requirements in the remaining paragraphs of section 12. In particular the second and third from last paragraphs state assumed requirements about the MIDCOM protocol and should be removed from this document. page 33 - references: the H.323 reference is out of date and should probably refer to H.323 V4 (2000) unless there was some specific (and not apparent) reason for referencing H.323 v2. === END of comments ==== Hope this helps. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 23 18:16:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27776 for ; Mon, 23 Jul 2001 18:16:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15776; Mon, 23 Jul 2001 18:06:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15750 for ; Mon, 23 Jul 2001 18:06:05 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27162 for ; Mon, 23 Jul 2001 18:05:10 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA04098; Mon, 23 Jul 2001 23:05:32 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA50778; Mon, 23 Jul 2001 23:05:21 +0100 Message-ID: <3B5C9F33.57279DDB@hursley.ibm.com> Date: Mon, 23 Jul 2001 17:03:31 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: richard.swale@bt.com CC: mduffy@quarrytech.com, midcom@ietf.org, sijben@lucent.com, philip.mart@marconi.com Subject: Re: [midcom] RE: comments on midcom-requirements-01 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit richard.swale@bt.com wrote: > > Mark, > ... > > 6. Also in 5.2.1, I believe that pinhole specification > > should be specified > > by "DSCP field" (high 6 bits of the old TOS octet) rather than by the > > now-obsolete "TOS field". This is probably also true for IPv6 traffic > > class field. I already commented that the correct phrase is "DS field" (that is the field that contains the DSCP value, if you want to be pedantic). Also it occurs to me that the IPv6 Flow Label should also be a (possibly wild carded) part of the pinhole spec. This is an active item now (draft-conta-ipv6-flow-label-02.txt) and it is certainly a potential requirement. For the record, I still object to the assertion in section 9 that the midcom protocol should be involved in QOS resource control, as was discussed here on June 29. Brian _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 23 18:22:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28043 for ; Mon, 23 Jul 2001 18:22:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15958; Mon, 23 Jul 2001 18:17:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15931 for ; Mon, 23 Jul 2001 18:17:14 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27786 for ; Mon, 23 Jul 2001 18:16:18 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6NMGu322372; Mon, 23 Jul 2001 15:16:56 -0700 (PDT) Received: from SBRIMW2K (sjc-vpn2-132.cisco.com [10.21.112.132]) by airborne.cisco.com (Mirapoint) with SMTP id AHP02448; Mon, 23 Jul 2001 15:16:45 -0700 (PDT) Message-ID: <045f01c113c5$27d91df0$6401a8c0@cisco.com> From: "Scott Brim" To: "Brian E Carpenter" , Cc: References: <3B5C9F33.57279DDB@hursley.ibm.com> Subject: Re: [midcom] RE: comments on midcom-requirements-01 Date: Mon, 23 Jul 2001 18:16:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Brian, I believe we've agreed not to address such possibilities at this time. However, at some future date I can conceive of an agent telling a middlebox "my client wants service to Tokyo and requests this kind of treatment for his traffic". If you're going to allow clients to make such requests at all, via RSVP or however, and you allow for the concept of agents at all, why wouldn't you allow agents to make such requests? Especially when many agents will simply be compartmentalization of intelligence which is already in some end systems. ...Scott ----- Original Message ----- From: "Brian E Carpenter" To: Cc: ; ; ; Sent: Monday, July 23, 2001 6:03 PM Subject: Re: [midcom] RE: comments on midcom-requirements-01 > For the record, I still object to the assertion in section 9 that the > midcom protocol should be involved in QOS resource control, as was > discussed here on June 29. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 23 19:03:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29488 for ; Mon, 23 Jul 2001 19:03:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16806; Mon, 23 Jul 2001 18:50:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16737 for ; Mon, 23 Jul 2001 18:50:02 -0400 (EDT) Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28994 for ; Mon, 23 Jul 2001 18:49:05 -0400 (EDT) Received: from ns-ca.netscreen.com (ns-ca.netscreen.com [10.100.10.21]) by mail.netscreen.com (8.10.0/8.10.0) with ESMTP id f6NM9aM13809; Mon, 23 Jul 2001 15:09:36 -0700 Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Jul 2001 15:49:21 -0700 Message-ID: From: John LaCour To: "'Scott Brim'" , Brian E Carpenter Cc: midcom@ietf.org Subject: RE: [midcom] RE: comments on midcom-requirements-01 Date: Mon, 23 Jul 2001 15:51:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org It seems to me that the DS field is part of the layer 3 header and therefore in scope. I would like to be able to use MIDCOM for QoS type things in the future. I'm ok focusing on pin-holes and NAT initially, but lets make sure that the Requirements reflect the ability to add additional functions to the protocol such as this in the future. I'd also like the Requirements to reflect the need to support custom/arbitrary/vendor specific MIDCOM requests. There are many protocols which support this concept such as DHCP, HTTP etc. This would allow me to use MIDCOM to ask my middlebox to perform functions that other middleboxes don't perform or for my middlebox to perform the task in a different way. Thoughts? Another general comment... there are several MIDCOM related drafts which are not reflected on the MIDCOM home page (http://www.ietf.org/html.charters/midcom-charter.html). It would probably be a good thing for people who are just now starting to do their homework on MIDCOM in preparation for the meeting to review these documents as well. Is there any way to get the homepage updated or is there a reason why these drafts are not included? -John > From: Scott Brim [mailto:sbrim@cisco.com] > Sent: Monday, July 23, 2001 3:17 PM > To: Brian E Carpenter; richard.swale@bt.com > Cc: midcom@ietf.org > Subject: Re: [midcom] RE: comments on midcom-requirements-01 > > Brian, I believe we've agreed not to address such > possibilities at this > time. However, at some future date I can conceive of an > agent telling a > middlebox "my client wants service to Tokyo and requests this kind of > treatment for his traffic". If you're going to allow clients > to make such > requests at all, via RSVP or however, and you allow for the concept of > agents at all, why wouldn't you allow agents to make such requests? > Especially when many agents will simply be compartmentalization of > intelligence which is already in some end systems. > > ...Scott > > ----- Original Message ----- > From: "Brian E Carpenter" > To: > Cc: ; ; ; > > Sent: Monday, July 23, 2001 6:03 PM > Subject: Re: [midcom] RE: comments on midcom-requirements-01 > > > > For the record, I still object to the assertion in section > 9 that the > > midcom protocol should be involved in QOS resource control, as was > > discussed here on June 29. > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 23 19:05:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29562 for ; Mon, 23 Jul 2001 19:05:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16717; Mon, 23 Jul 2001 18:48:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16688 for ; Mon, 23 Jul 2001 18:48:47 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28915 for ; Mon, 23 Jul 2001 18:47:51 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6NMmEg28086; Mon, 23 Jul 2001 15:48:18 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-344.cisco.com [10.21.65.88]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ARN11359; Mon, 23 Jul 2001 15:48:08 -0700 (PDT) Message-Id: <5.1.0.14.0.20010723184530.00a28760@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 23 Jul 2001 18:49:18 -0400 To: Mark Duffy , midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Framework last call -- level of middlebox intelligence In-Reply-To: <3.0.5.32.20010723165306.00961450@10.1.1.249> References: <15196.30969.360000.269188@gargle.gargle.HOWL> <3.0.5.32.20010723145327.00863320@10.1.1.249> <3.0.5.32.20010720153341.0085e990@10.1.1.249> <3.0.5.32.20010723145327.00863320@10.1.1.249> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 04:53 PM 7/23/01 -0400, Mark Duffy wrote: >Why am I looking for this? Because without stating this we in fact have >very little. It doesn't mean much to say midcom allows moving the >"application" intelligence from the middlebox to the midcom agent if one >does not define where the "applications" begin. No? That's an excellent point. We (the collective "we" - there's certainly been some disagreement, however) have been assuming that we're dealing with transport-layer middleboxes and there seems to be some consensus around having us not skip past the transport (TCP, UDP, SCTP) headers. We must stay mindful, however, of the possibility that either future iterations or vendor-proprietary extensions will want to go deeper into the packet, and must therefore require that the protocol be sufficiently expressive to allow something beyond {address, port, proto}. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 23 19:22:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00482 for ; Mon, 23 Jul 2001 19:22:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17348; Mon, 23 Jul 2001 19:07:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17322 for ; Mon, 23 Jul 2001 19:07:58 -0400 (EDT) Received: from nrmail01.netrake.net (403217BD.ptr.dia.nextlink.net [64.50.23.189]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29636 for ; Mon, 23 Jul 2001 19:07:04 -0400 (EDT) Received: from NRPC128 (nrpc-128 [10.10.111.128]) by nrmail01.netrake.net (8.11.1/8.11.1) with SMTP id f6NN7LB12602; Mon, 23 Jul 2001 18:07:21 -0500 From: "Ken Rong" To: "Melinda Shore" , "Mark Duffy" , Subject: RE: [midcom] Framework last call -- level of middlebox intelligence Date: Mon, 23 Jul 2001 18:07:21 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <5.1.0.14.0.20010723184530.00a28760@mira-sjc5-4.cisco.com> 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 Can the protocol specification be open/flexible enough to accomodate deeper look up? I understand that beyond 5 tuples, scenarios can be very different. But most application intelligence are really in the payload of packets. Thanks, Ken Rong Netrake Corp Richardson, Texas -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Melinda Shore Sent: Monday, July 23, 2001 5:49 PM To: Mark Duffy; midcom@ietf.org Subject: Re: [midcom] Framework last call -- level of middlebox intelligence At 04:53 PM 7/23/01 -0400, Mark Duffy wrote: >Why am I looking for this? Because without stating this we in fact have >very little. It doesn't mean much to say midcom allows moving the >"application" intelligence from the middlebox to the midcom agent if one >does not define where the "applications" begin. No? That's an excellent point. We (the collective "we" - there's certainly been some disagreement, however) have been assuming that we're dealing with transport-layer middleboxes and there seems to be some consensus around having us not skip past the transport (TCP, UDP, SCTP) headers. We must stay mindful, however, of the possibility that either future iterations or vendor-proprietary extensions will want to go deeper into the packet, and must therefore require that the protocol be sufficiently expressive to allow something beyond {address, port, proto}. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 23 19:22:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00524 for ; Mon, 23 Jul 2001 19:22:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17540; Mon, 23 Jul 2001 19:15:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17474 for ; Mon, 23 Jul 2001 19:15:07 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29979 for ; Mon, 23 Jul 2001 19:14:12 -0400 (EDT) Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PDZ5560N; Mon, 23 Jul 2001 19:14:39 -0400 Message-Id: <3.0.5.32.20010723182154.0097abd0@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 23 Jul 2001 18:21:54 -0400 To: Pyda Srisuresh , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Framework last call In-Reply-To: <20010722192129.60728.qmail@web13807.mail.yahoo.com> References: <3.0.5.32.20010720153341.0085e990@10.1.1.249> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Suresh, last of my 4 followup questions. Thanks and sorry about the volume of all this! >> [Mark] >> . Section 8.4 -- timers: "However, the middlebox should be able to recover >> the dynamically allocated resources even as the agent that was responsible >> for the allocation is not alive." Does that mean "recover even while >> still alive" or "recover when not alive"? > [Suresh] >Recovering when the agent is alive happens by design, when the dynamically >allocated resources are no longer required. I agree with your statement immediately above. However, I'm not sure whether the text (quoted above) from the 2nd paragraph of 8.4 refers to the case where the agent is no longer alive, or to a case where is is still alive and in contact. If it is about the the former, it might be clarified by changing "even as" to "even when". (This is just a trivial question on the wording.) On a more substantive note, I would like to ask about the following. The draft discusses middlebox resources allocated by an agent and then being freed: - by explicit direction from the Agent - by expiration of a timer - by loss of the session with the agent (for various reasons) I would suggest that in some cases not all of those would be desired and therefore it could be selected when the resource is assigned, and typically controlled by the agent, which way(s) the resource would be freed. For example, an agent opening a firewall pinhole might ask the middlebox to keep the pinhole open even if the midcom session is lost (presumably the middlebox would require a non-infinite timeout in this case). Another agent might request the pinhole remain open until the midcom session is broken or the agent explitly requests its removal. Yet another agent may request a pinhole be closed on expiration of a timer or when the midcom sesion is lost, whichever comes first. Is there interest in this? Is this too detailed for the framework document? Currently, many firewalls will automatically close tcp pinholes when they see the close of a tcp session. I suggest that might also be a trigger the middlebox could be instructed to watch for. --Regards, Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 23 19:25:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00661 for ; Mon, 23 Jul 2001 19:25:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17534; Mon, 23 Jul 2001 19:15:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17477 for ; Mon, 23 Jul 2001 19:15:07 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29980 for ; Mon, 23 Jul 2001 19:14:12 -0400 (EDT) Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PDZ5560P; Mon, 23 Jul 2001 19:14:39 -0400 Message-Id: <3.0.5.32.20010723190058.0097a9b0@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 23 Jul 2001 19:00:58 -0400 To: "Scott Brim" From: Mark Duffy Subject: Re: [midcom] Framework last call -- level of middlebox intelligence Cc: midcom@ietf.org In-Reply-To: <15196.37506.780000.664563@gargle.gargle.HOWL> References: <3.0.5.32.20010723165306.00961450@10.1.1.249> <3.0.5.32.20010723145327.00863320@10.1.1.249> <3.0.5.32.20010720153341.0085e990@10.1.1.249> <3.0.5.32.20010723165306.00961450@10.1.1.249> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi Scott, My personal "requirements" would be mostly along the lines of keeping the amount of application intelligence required in the middlebox as low as possible. I guess I spoke a little loosely about "how deep in the packet". I wasn't talking literally about how many bytes into the packet, but rather how many protocols the middlebox would need to understand and parse to classify the packet. It seems to be a given at this point that middleboxes will need to be told to look for certain values of source/destination addresses, protocol, and source/destination ports. The implication is that the middlebox needs to be able to find the IP, TCP, and UDP headers and examine those fields. Well that is just fine with me. What I am trying to tease out here is whether participating in a midcom environment will require the middlebox to be able to understand and/or examine headers aside from IP, UDP, TCP. I suppose extension beyond those could take the form of either specific protocols/headers to understand, or the ability to be told to blindly look at certain offsets for certain values, without really understanding what the headers are (would work for some protocols). Personally, I'm not too keen on going beyond tcp/udp. I suppose going beyond there will be based on the intersection of what is needed to do middlebox functions for a particular application of interest, how expressive the midcom protocol is, and what various middlebox products are capable of. BTW, I was really trying to understand what the consensus of the group was in this area, not to propose changes. -- Mark At 05:09 PM 7/23/01 -0400, Scott Brim wrote: >Hi Mark. More detail ... That's exactly my point. You're asking "how >deep in the packet should a middlebox look", and my answer is "as deep >as it has to". How deep is that? That depends on what the requirements >are. If nobody has a need for a middlebox to look deeper than the IP >header, then we can stop there. So, what needs do you personally see? >Do you see any reason to go deeper? If so, we can include your >requirements, and justifications for them, in the requirements draft. >"What are your requirements" was meant to be shorthand for all that. > >...Scott > >On 23 Jul 2001 at 16:53 -0400, Mark Duffy apparently wrote: >> At 03:20 PM 7/23/01 -0400, Scott Brim wrote: >> >On 23 Jul 2001 at 14:53 -0400, Mark Duffy apparently wrote: >> >> Yes, the document is quite clear that the application intelligence is to be >> >> in the agents. What I would like to get clarified is exactly how much >> >> "intelligence" needs to remain in the middlebox after that "application" >> >> intelligence is moved out. >> > >> >What are your requirements? Why? >> >> Scott, I'm not sure I understand your question. >> My message was not about adding any requirements on midcom, if perchance >> that's what you are asking. >> >> The agents will use the midcom protocol to tell middleboxes to do >> particular things to/for particular packets. As asked in detail in the >> rest of my posting of which you quote a part, I am looking for >> clarification (in the framework document) as to how deep in the packet the >> middlebox is expected to examine and what protocol headers the middlebox is >> expected to understand. >> >> Why am I looking for this? Because without stating this we in fact have >> very little. It doesn't mean much to say midcom allows moving the >> "application" intelligence from the middlebox to the midcom agent if one >> does not define where the "applications" begin. No? >> >> -Mark >> >> > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 23 19:50:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02155 for ; Mon, 23 Jul 2001 19:50:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18218; Mon, 23 Jul 2001 19:41:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18192 for ; Mon, 23 Jul 2001 19:41:22 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01626 for ; Mon, 23 Jul 2001 19:40:28 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6NNf6T13024; Mon, 23 Jul 2001 16:41:06 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-344.cisco.com [10.21.65.88]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ARO00376; Mon, 23 Jul 2001 16:40:53 -0700 (PDT) Message-Id: <5.1.0.14.0.20010723193832.00a1a570@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 23 Jul 2001 19:42:02 -0400 To: "Ken Rong" , From: Melinda Shore Subject: RE: [midcom] Framework last call -- level of middlebox intelligence In-Reply-To: References: <5.1.0.14.0.20010723184530.00a28760@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 06:07 PM 7/23/01 -0500, Ken Rong wrote: >Can the protocol specification be open/flexible enough to accomodate deeper >look up? I understand that beyond 5 tuples, scenarios can be very >different. But most application intelligence are really in the payload of >packets. I'd actually say that some not-insignificant portion of the application's intelligence resides in application state and transaction state and not in the packet at all. I think the question that we need to answer is what information the application needs to convey to a firewall or NAT in order for the middlebox to be able to correctly identify application packets for traversal purposes, translation, etc. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 23 20:42:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04826 for ; Mon, 23 Jul 2001 20:42:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19022; Mon, 23 Jul 2001 20:23:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA18995 for ; Mon, 23 Jul 2001 20:23:40 -0400 (EDT) Received: from nrmail01.netrake.net (403217BD.ptr.dia.nextlink.net [64.50.23.189]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03889 for ; Mon, 23 Jul 2001 20:22:45 -0400 (EDT) Received: from NRPC128 (nrpc-128 [10.10.111.128]) by nrmail01.netrake.net (8.11.1/8.11.1) with SMTP id f6O0N5B14562; Mon, 23 Jul 2001 19:23:05 -0500 From: "Ken Rong" To: "Melinda Shore" , Subject: RE: [midcom] Framework last call -- level of middlebox intelligence Date: Mon, 23 Jul 2001 19:23:05 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <5.1.0.14.0.20010723193832.00a1a570@mira-sjc5-4.cisco.com> 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 "Application State" and "Transcation State" may cover lots of stuff. For the SIP example used in the draft, I do need to get the RTP port number from the packet payload in order to apply specific logic to the real call traffic. Without getting into the payload, how can I do that? Ken -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Monday, July 23, 2001 6:42 PM To: Ken Rong; midcom@ietf.org Subject: RE: [midcom] Framework last call -- level of middlebox intelligence At 06:07 PM 7/23/01 -0500, Ken Rong wrote: >Can the protocol specification be open/flexible enough to accomodate deeper >look up? I understand that beyond 5 tuples, scenarios can be very >different. But most application intelligence are really in the payload of >packets. I'd actually say that some not-insignificant portion of the application's intelligence resides in application state and transaction state and not in the packet at all. I think the question that we need to answer is what information the application needs to convey to a firewall or NAT in order for the middlebox to be able to correctly identify application packets for traversal purposes, translation, etc. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 23 20:53:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05270 for ; Mon, 23 Jul 2001 20:53:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19515; Mon, 23 Jul 2001 20:45:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19486 for ; Mon, 23 Jul 2001 20:45:28 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04947 for ; Mon, 23 Jul 2001 20:44:33 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6O0j5g23516; Mon, 23 Jul 2001 17:45:05 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-344.cisco.com [10.21.65.88]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ARO02848; Mon, 23 Jul 2001 17:44:56 -0700 (PDT) Message-Id: <5.1.0.14.0.20010723204415.009f5220@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 23 Jul 2001 20:46:04 -0400 To: "Ken Rong" , From: Melinda Shore Subject: RE: [midcom] Framework last call -- level of middlebox intelligence In-Reply-To: References: <5.1.0.14.0.20010723193832.00a1a570@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 07:23 PM 7/23/01 -0500, Ken Rong wrote: >"Application State" and "Transcation State" may cover lots of stuff. For >the SIP example used in the draft, I do need to get the RTP port number from >the packet payload in order to apply specific logic to the real call >traffic. Without getting into the payload, how can I do that? That (having the middlebox snag the port number from the signaling payload) is precisely the situation we're trying to rectify. An endpoint/ALG/proxy will have knowledge of the port number and would be able to convey it to the middlebox. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 24 13:37:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05075 for ; Tue, 24 Jul 2001 13:37:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25559; Tue, 24 Jul 2001 13:35:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25528 for ; Tue, 24 Jul 2001 13:35:06 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04827 for ; Tue, 24 Jul 2001 13:34:07 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6OHYi308300 for ; Tue, 24 Jul 2001 10:34:44 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-407.cisco.com [10.21.65.151]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ARQ04984; Tue, 24 Jul 2001 10:34:34 -0700 (PDT) Message-Id: <5.1.0.14.0.20010724133259.00a2eec0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 24 Jul 2001 13:35:41 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Bar BOF! Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I'd like to propose a bar BOF at the London meeting, scheduled at 1930 on Monday, 6 August. The topic would be the requirements draft - its structure and identifying outstanding issues which need to be discussed in the full meeting on Friday. Please let me know if you feel you absolutely must be there but the time doesn't work for you. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jul 25 06:38:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08151 for ; Wed, 25 Jul 2001 06:38:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28894; Wed, 25 Jul 2001 06:36:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28867 for ; Wed, 25 Jul 2001 06:36:38 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07922; Wed, 25 Jul 2001 06:35:39 -0400 (EDT) Message-Id: <200107251035.GAA07922@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: Wed, 25 Jul 2001 06:35:39 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-requirements-02.txt,.ps Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : Middlebox Control (MIDCOM) Protocol Architecture and Requirements Author(s) : R. Swale, P. Mart, P. Sijben Filename : draft-ietf-midcom-requirements-02.txt,.ps Pages : 15 Date : 24-Jul-01 Networks connecting to and forming part of the Internet are increasingly deploying specialised network functions to address security, quality of service and other administrative policy requirements. These devices are a subset of what can be referred to as 'Middleboxes'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-requirements-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-requirements-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-requirements-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132635.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-requirements-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132635.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Jul 25 11:03:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28836 for ; Wed, 25 Jul 2001 11:03:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07269; Wed, 25 Jul 2001 10:52:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07238 for ; Wed, 25 Jul 2001 10:52:18 -0400 (EDT) Received: from web13808.mail.yahoo.com (web13808.mail.yahoo.com [216.136.175.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27687 for ; Wed, 25 Jul 2001 10:51:18 -0400 (EDT) Message-ID: <20010725145215.9294.qmail@web13808.mail.yahoo.com> Received: from [65.12.33.187] by web13808.mail.yahoo.com; Wed, 25 Jul 2001 07:52:15 PDT Date: Wed, 25 Jul 2001 07:52:15 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Framework last call -- nonnative agents To: Mark Duffy , midcom@ietf.org In-Reply-To: <3.0.5.32.20010723171951.009935f0@10.1.1.249> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --- Mark Duffy wrote: > Suresh, see below... > > >> [Mark] > >> . In 5.0 it states "In-Path MIDCOM agents are entities that have a native > >> role in the path of the application traversal ... idependent of their > >> MIDCOM function." Why must they have a native role? This would pretty > >> much eliminate using midcom for any applications that don't already employ > >> such devices. I don't see any reason to exclude agent devices placed > there > >> solely for the purpose of being an in-path Midcom Agent. I propose we > >> revise that sentence to read: "In-Path MIDCOM agents are MIDCOM agents > that > >> are located naturally within the message path of the application they are > >> associated with." Or strike the sentence entirely since this is just > >> repeating the definition presented in section 2.8. > >> > > > {Suresh] > >You are right about the interpretation of the definition. That was the > >intention. What non-native kind did you have in mind? > > I don't have any specific kind in mind but let's use ftp as an example. > For the sake of the example suppose that ftp proxies will not be used. > > Passing ftp through a NAT box requires an ftp-aware ALG function to modify > data on the ftp control session. Today this ALG would perhaps be a > component of the NAT middlebox. In the spirit of midcom, I would like to > leave open the possibility to remove the ftp application intelligence from > the middlebox and deploy it instead in a Midcom Agent. > Sounds good. > Since there is not necessarily any ftp-aware box already in the network > (excepting the end points) we might want to deploy an ftp-aware midcom > agent device expressly for the purpose of controlling the non-ftp-aware > middlebox. This device would not have a native role in the path of the > application traversal idependent of the MIDCOM function, but I don't see > why it should therefore be excluded by the midcom framework. In other > words, why should midcom care what (if anything) else the agent device does > outside of its midcom role? If the device is not natively in the path (i.e, terminating a session along the way and visible to end-hosts), that would be an intermediate device forwarding packets along the route (such as a switch, a router or a VPN device etc.) that would be hosting the MIDCOM agent function. Yes, that does make sense. I will reword as you suggest. Thanks. > > --Mark > > regards, suresh __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 26 11:12:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16417 for ; Thu, 26 Jul 2001 11:12:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21698; Thu, 26 Jul 2001 10:46:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21667 for ; Thu, 26 Jul 2001 10:46:37 -0400 (EDT) Received: from web13802.mail.yahoo.com (web13802.mail.yahoo.com [216.136.175.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13875 for ; Thu, 26 Jul 2001 10:45:36 -0400 (EDT) Message-ID: <20010726143953.10570.qmail@web13802.mail.yahoo.com> Received: from [65.12.33.187] by web13802.mail.yahoo.com; Thu, 26 Jul 2001 07:39:53 PDT Date: Thu, 26 Jul 2001 07:39:53 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Comments on Framework 03 draft To: richard.swale@bt.com, midcom@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --- richard.swale@bt.com wrote: > Hi, > > I have a number of comments on the 03 draft. > > 1. The In-path and out-of-path issue doesn't seem to have closed and there > is plenty of reference to it in the document. I dont believe so. The In-path vs OOP issue is closed. The document does not refer OOP agents other than simply stating that the discussion is out of scope. > I have been thinking about the > view the protocol gets and it seems to be easier to position the protocol as > flowing between a middlebox and an Agent only - as per the text in some > places. The in-path and out-of -path issue then only becomes part of the > debate if the actual MIDCOM Agent is interpreted to be the whole ALG > function - which the document does in some places. If on the other hand, the > MIDCOM Agent is considered to be only that part of an ALG that talks to the > Middlebox from a control point of view, then the whole in-path and out > -of-path debate disappears. i.e. > Richard - I wouldnt want to change the definition and function of an agent to be the least common factor (i.e., between In-Path and OOP). Limiting the definition to control and ignoring application data traffic would be incomplete. Besides, the text, illustrations and WG discussion thus far has been built around the current definition. I would rather not change that. > +--------------+ > +--------------------+ > | ALG | | ALG > | > +--------------+ | +---------+ > | > | MCA | | | MCA | | > | | | | > | | > + -------------+ > +---+----------+----+ > ^ ^ > | | > v v > +------------------+ > +------------------+ > | MIddlebox | | Middlebox | > +-------------------+ > +------------------+ > Your figures are garbled. > Where MCA is the MIDCOM Agent. In the second case, the ALG would use the > MIDCOM Agent to route the session control streams (e.g. SIP messages) to the > ALG on another logical interface to the ALG as opposed to coming through the > Agent. If this is the case then whether the function the agent is part of > (i.e. the bigger ALG function) sits in the signalling path or not becomes > irelevant. So from this point of view I think it may be better to position > the MIDCOM Agent as purely being that part of a bigger function which > communicate with the Middlebox for command and control purposes. If this > approach is agreeable, then the discussion concerning in-path and > out-of-path can come out of the document. > It is not my intention to work around the definition to fit the OOP agents. We had a spirited discussion and concluded that OOP agents is out of scope. I will go with that. > Section 4 seems to have lots of embedded requirements concerning the > protocol. Is this the right place to put this stuff? I would suggest > possibly not. > Richard - The framework cannot be described in a vacuum. The section simply talks about the phases in a MIDCOM connection setup. While some overlap is inevitable, it is important to note that (a) the reader is not required to have two documents (i.e., framework and requriements document) in order to understand this document, (b) the requirements and framework document should be in sync. As far as I can tell, the focus of the text throughout has been the framework in which the MIDCOM protocol will operate. > Section 5 seems to have a lot of common text with section 2.8. Could these > be merged? > 2.8 is term definition for MIDCOM agent. 5.0 is description and discussion on MIDCOM agents. Some overlap is inevitable. I wouldnt want to merge the two. > Section 6.1 seems to have a lot of embedded requirements > > Section 6.2 also seems to have a lot of embedded requirements > Please see my comments earlier. > Section 8.2 seems to repeat section 4 and section 6.2. > You are right. I will get rid of the text in section 8.2. > nits > === > Page 1 and elsewhere. NetMeeting V3.x isn't always a peer-peer application > so it is a bit misleading to cite it. It can be - but not always. > I dont know about specific versions. I dont find this misleading. > I think the term "Message Sequence" might read a bit better than "Timeline > Flow" in section 7 > It is just a word - same meaning. Works for me and many others. I would leave it as is. > Section 8.6 makes reference to Q.931 which technically isn't correct and > should probably read H.225.0 call signalling. > Q.931 is the packet format exchanged over H.323 TCP connection. The Intel document that describes H.323 also refers the Q.931 and H.323 connections interchangeably. So, I suggest, we leave this as is. > Hope this helps. > Thanks. > regards > > Richard > regards, suresh __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 26 11:17:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17156 for ; Thu, 26 Jul 2001 11:17:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22446; Thu, 26 Jul 2001 11:12:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22421 for ; Thu, 26 Jul 2001 11:12:54 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16398 for ; Thu, 26 Jul 2001 11:11:54 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6QFCNg29528 for ; Thu, 26 Jul 2001 08:12:23 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp220.cisco.com [10.21.64.220]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ASF04065; Thu, 26 Jul 2001 08:12:21 -0700 (PDT) Message-Id: <5.1.0.14.0.20010726110851.00a24390@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 26 Jul 2001 11:13:36 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Document formatting Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Taking off my chair cap here ... A number of people have noted that using proprietary word processing programs to produce ASCII documents simply doesn't work very well and that the results can be suboptimal (non- printing characters showing up in text, etc.). In the interest of making documents available to the broadest number of readers regardless of platform, I'd be happy to help anyone producing documents for *this* (midcom) audience convert their text to nroff/troff, including tbl, eqn, pic, etc. If someone wants to step forward and volunteer to help with other non-proprietary, portable formats (XML, TeX) I'm sure that would be appreciated, too. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 26 13:33:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23665 for ; Thu, 26 Jul 2001 13:33:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25294; Thu, 26 Jul 2001 12:30:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25265 for ; Thu, 26 Jul 2001 12:30:37 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20675 for ; Thu, 26 Jul 2001 12:29:36 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6QF73g25983 for ; Thu, 26 Jul 2001 08:07:03 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp220.cisco.com [10.21.64.220]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ASF03925; Thu, 26 Jul 2001 08:06:57 -0700 (PDT) Message-Id: <5.1.0.14.0.20010726110038.00a1b290@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 26 Jul 2001 11:08:13 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Status reminder Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org 1) We will be meeting on Friday, 10 August at 9am during the upcoming IETF meeting. 2) There will be a bar BOF on Monday, 6 August at 1930 - location to be announced. The topic will be the requirements document 3) We are in working group last call on the framework document. Last call closes on Friday, 3 August. The current versions of the drafts are: http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-03.txt http://www.ietf.org/internet-drafts/draft-ietf-midcom-requirements-02.txt Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 26 14:28:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01424 for ; Thu, 26 Jul 2001 14:28:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29328; Thu, 26 Jul 2001 14:26:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29288 for ; Thu, 26 Jul 2001 14:26:17 -0400 (EDT) Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01191 for ; Thu, 26 Jul 2001 14:25:16 -0400 (EDT) From: richard.swale@bt.com Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP; Thu, 26 Jul 2001 19:24:52 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Thu, 26 Jul 2001 19:24:51 +0100 Message-ID: To: srisuresh@yahoo.com, midcom@ietf.org Subject: RE: [midcom] Comments on Framework 03 draft Date: Thu, 26 Jul 2001 19:24:00 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi, Thanks for the status update:- > > 1. The In-path and out-of-path issue doesn't seem to have > closed and there > > is plenty of reference to it in the document. > > I dont believe so. The In-path vs OOP issue is closed. > The document does not refer OOP agents other than simply stating > that the discussion is out of scope. > I think this needs discussing further then as I'm getting a lot of discussion on the subject off the list. > Richard - The framework cannot be described in a vacuum. The section > simply talks about the phases in a MIDCOM connection setup. While some > overlap is inevitable, it is important to note that (a) the > reader is not > required to have two documents (i.e., framework and > requriements document) > in order to understand this document, (b) the requirements > and framework > document should be in sync. Unfortuantely this is precisely the reason the requirements should not be in the framework document - both documents should do one job only. If we produce a framework document which implies requirements which have been neither agreed nor aligned with the requirements document we will invariably have people implementing to assumed and therefore incorrect requirements. End result will be two solutions, neither of which will interwork necessarily. > > Section 5 seems to have a lot of common text with section > 2.8. Could these > > be merged? > > > 2.8 is term definition for MIDCOM agent. > 5.0 is description and discussion on MIDCOM agents. > Some overlap is inevitable. I wouldnt want to merge the two. > > > Section 6.1 seems to have a lot of embedded requirements > > > > Section 6.2 also seems to have a lot of embedded requirements > > nits > > === > > Page 1 and elsewhere. NetMeeting V3.x isn't always a > peer-peer application > > so it is a bit misleading to cite it. It can be - but not always. > > > I dont know about specific versions. I dont find this misleading. Or to be blunt what you have said is factually inaccurate. It is simply an true statement. > > Section 8.6 makes reference to Q.931 which technically > isn't correct and > > should probably read H.225.0 call signalling. > > > > Q.931 is the packet format exchanged over H.323 TCP connection. > The Intel document that describes H.323 also refers the Q.931 > and H.323 connections interchangeably. So, I suggest, > we leave this as is. > Sorry - H.323 is an ITU-T specification not an Intel one! H.323 call signalling is defined in H.225.0 which contains a profile of Q.931 (it uses the balanced mode of operation). Therefore the call signalling in H.323 is defined in H.225.0 and not Q.931 - that is a different document and specification all together. I suggest we change it to make it factually acurate. regards Richard _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 26 15:30:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05819 for ; Thu, 26 Jul 2001 15:30:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01506; Thu, 26 Jul 2001 15:28:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01475 for ; Thu, 26 Jul 2001 15:28:18 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05649 for ; Thu, 26 Jul 2001 15:27:17 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6QJRng24268; Thu, 26 Jul 2001 12:27:49 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp220.cisco.com [10.21.64.220]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ASI02011; Thu, 26 Jul 2001 12:27:42 -0700 (PDT) Message-Id: <5.1.0.14.0.20010726152224.00a2e6e0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 26 Jul 2001 15:28:57 -0400 To: richard.swale@bt.com, srisuresh@yahoo.com, midcom@ietf.org From: Melinda Shore Subject: RE: [midcom] Comments on Framework 03 draft 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 07:24 PM 7/26/01 +0100, richard.swale@bt.com wrote: >I think this [OOP agents] needs discussing further then as I'm getting a lot of >discussion on the subject off the list. The matter has been closed for some weeks on this list, and this list is the place where the working group tries to reach agreement. The only thing I can see in the framework document that might seem to be in violation of the decision is the use of the phrase "In-path agents," but inasmuch as the document explicitly says that the only thing being considered is in-path agents I really don't see a problem. Again, we're in last call. Objections need to be specific. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 26 17:00:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11795 for ; Thu, 26 Jul 2001 17:00:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03820; Thu, 26 Jul 2001 16:52:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03791 for ; Thu, 26 Jul 2001 16:52:24 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11173 for ; Thu, 26 Jul 2001 16:51:25 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id QAA05141; Thu, 26 Jul 2001 16:52:18 -0400 (EDT) Message-Id: <200107262052.QAA05141@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Melinda Shore cc: richard.swale@bt.com, srisuresh@yahoo.com, midcom@ietf.org Subject: Re: [midcom] Comments on Framework 03 draft In-reply-to: Your message of "Thu, 26 Jul 2001 15:28:57 EDT." <5.1.0.14.0.20010726152224.00a2e6e0@mira-sjc5-4.cisco.com> Date: Thu, 26 Jul 2001 16:52:18 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > Again, we're in last call. Objections need to be specific. oh, come on. it's one thing to insist that discussions be on the list, but the fact that the chair has declared a last call does not mean that the document only needs minor tweaking before it goes forward. it's entirely reasonable for WG participants to push back with more general objections. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 26 17:18:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12891 for ; Thu, 26 Jul 2001 17:18:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04755; Thu, 26 Jul 2001 17:18:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04724 for ; Thu, 26 Jul 2001 17:18:30 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12802 for ; Thu, 26 Jul 2001 17:17:30 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6QLI6325172; Thu, 26 Jul 2001 14:18:06 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp220.cisco.com [10.21.64.220]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ASI06123; Thu, 26 Jul 2001 14:17:52 -0700 (PDT) Message-Id: <5.1.0.14.0.20010726171748.00a1d140@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 26 Jul 2001 17:19:06 -0400 To: Keith Moore From: Melinda Shore Subject: Re: [midcom] Comments on Framework 03 draft Cc: richard.swale@bt.com, srisuresh@yahoo.com, midcom@ietf.org In-Reply-To: <200107262052.QAA05141@astro.cs.utk.edu> References: 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:52 PM 7/26/01 -0400, Keith Moore wrote: >oh, come on. it's one thing to insist that discussions be on the list, >but the fact that the chair has declared a last call does not mean that >the document only needs minor tweaking before it goes forward. Of course not, and that's not the issue. "The text in section xxx is incorrect" is helpful; "there's too much stuff about OOP agents" when there's virtually nothing on OOP agents is not. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 26 17:28:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13387 for ; Thu, 26 Jul 2001 17:28:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04906; Thu, 26 Jul 2001 17:28:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04877 for ; Thu, 26 Jul 2001 17:28:03 -0400 (EDT) Received: from gollum.axion.bt.co.uk (gollum.axion.bt.co.uk [132.146.17.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13309 for ; Thu, 26 Jul 2001 17:27:02 -0400 (EDT) From: richard.swale@bt.com Received: from cbtlipnt02.btlabs.bt.co.uk by gollum (local) with ESMTP; Thu, 26 Jul 2001 22:26:53 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Thu, 26 Jul 2001 22:26:15 +0100 Message-ID: To: mshore@cisco.com, moore@cs.utk.edu Cc: srisuresh@yahoo.com, midcom@ietf.org Subject: RE: [midcom] Comments on Framework 03 draft Date: Thu, 26 Jul 2001 22:26:02 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Perhaps in a spirit of trying to appear helpful (which I believe I am trying to be) I could go back to my observation which I think started this little flurry. It was basicly that this In-Out of path thing may not be an issue from the point of view of specifying the requirements of the MIDCOM protocol. The reason for this I thought I had started to express in the suggested revisions to the framework draft - I wonder whether this point has kind of been lost in this? Are we going to have in-path/out-path and do we really-care-from-the-point-of view-of-the-MIDCOM-protocol as a discussion point for the meeting/pub bash in London? regards Richard > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: 26 July 2001 22:19 > To: Keith Moore > Cc: richard.swale@bt.com; srisuresh@yahoo.com; midcom@ietf.org > Subject: Re: [midcom] Comments on Framework 03 draft > > > At 04:52 PM 7/26/01 -0400, Keith Moore wrote: > >oh, come on. it's one thing to insist that discussions be > on the list, > >but the fact that the chair has declared a last call does > not mean that > >the document only needs minor tweaking before it goes forward. > > Of course not, and that's not the issue. "The text in section xxx is > incorrect" is helpful; "there's too much stuff about OOP agents" when > there's virtually nothing on OOP agents is not. > > Melinda > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 26 17:46:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15429 for ; Thu, 26 Jul 2001 17:46:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05610; Thu, 26 Jul 2001 17:46:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05581 for ; Thu, 26 Jul 2001 17:46:18 -0400 (EDT) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15314 for ; Thu, 26 Jul 2001 17:45:16 -0400 (EDT) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f6QLdtd04848; Thu, 26 Jul 2001 14:39:55 -0700 (PDT) Message-ID: <0e9601c1161c$5c183430$8753cf3f@FATORA> From: "Marshall T. Rose" To: , "Melinda Shore" Cc: "Marshall Rose" References: <5.1.0.14.0.20010726110851.00a24390@mira-sjc5-4.cisco.com> Subject: Re: [midcom] Document formatting Date: Thu, 26 Jul 2001 14:45:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 author in xml and produce .txt (rfc/i-d), html, and nroff... c.f., rfc 2629 and http://xml.resource.org/ /mtr ----- Original Message ----- From: "Melinda Shore" To: Sent: Thursday, July 26, 2001 08:13 Subject: [midcom] Document formatting > Taking off my chair cap here ... > > A number of people have noted that using proprietary word > processing programs to produce ASCII documents simply doesn't > work very well and that the results can be suboptimal (non- > printing characters showing up in text, etc.). In the interest > of making documents available to the broadest number of readers > regardless of platform, I'd be happy to help anyone producing > documents for *this* (midcom) audience convert their text to > nroff/troff, including tbl, eqn, pic, etc. If someone wants > to step forward and volunteer to help with other non-proprietary, > portable formats (XML, TeX) I'm sure that would be appreciated, > too. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 26 18:33:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18323 for ; Thu, 26 Jul 2001 18:33:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06368; Thu, 26 Jul 2001 18:28:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06337 for ; Thu, 26 Jul 2001 18:28:04 -0400 (EDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18005 for ; Thu, 26 Jul 2001 18:27:04 -0400 (EDT) Received: from cisco.com (elear-dsl1.cisco.com [10.19.144.50]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA12425; Thu, 26 Jul 2001 15:27:32 -0700 (PDT) Message-ID: <3B6099F3.2020402@cisco.com> Date: Thu, 26 Jul 2001 15:30:11 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 X-Accept-Language: en-us MIME-Version: 1.0 To: srisuresh@yahoo.com CC: midcom@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] framework 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 2.3 Definition of Firewall "packet filtering" is but one type of firewall. We should borrow a better definition from elsewhere. Figure 3 - you skipped or removed step "5". I'm also interested in changing some wording to the protocol requirements, and a more general statement about protocol layering. Bob Braden's recent post to the IETF I think is most concerning. It is necessary for authorization to occur within the midcom protocol. The conditions of that authorization may be based on characteristics taken from any part of the protocol stack. That is the nature of policy. However, the communication that is authorized is a TCP/UDP/SCTP/etc. tuple. The way these decisions are made may require the midcom agent to pass to the middlebox opaque application level information that it MAY in turn pass onto an appropriate policy server. This information does need to be structured and supported by the protocol, and may even be multiple blocks that are passed to different policy servers. Consider a policy server that handles voice, allowing voice sessions of < 64 kb/s for lengths of time <= 4 hours, but a separate policy server that restricts communications with my competitors and stock broker ;-) I want to be able to make some statement about "no gnutella files of type mpg or avi, but allow mp3" or not. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 26 20:38:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26133 for ; Thu, 26 Jul 2001 20:38:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09838; Thu, 26 Jul 2001 20:34:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA09805 for ; Thu, 26 Jul 2001 20:34:30 -0400 (EDT) Received: from web13801.mail.yahoo.com (web13801.mail.yahoo.com [216.136.175.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26007 for ; Thu, 26 Jul 2001 20:33:30 -0400 (EDT) Message-ID: <20010727003428.88033.qmail@web13801.mail.yahoo.com> Received: from [66.89.112.150] by web13801.mail.yahoo.com; Thu, 26 Jul 2001 17:34:28 PDT Date: Thu, 26 Jul 2001 17:34:28 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [midcom] Comments on Framework 03 draft To: richard.swale@bt.com Cc: midcom@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --- richard.swale@bt.com wrote: > Perhaps in a spirit of trying to appear helpful (which I believe I am trying > to be) I could go back to my observation which I think started this little > flurry. It was basicly that this In-Out of path thing may not be an issue > from the point of view of specifying the requirements of the MIDCOM > protocol. The reason for this I thought I had started to express in the > suggested revisions to the framework draft - I wonder whether this point has > kind of been lost in this? > The agent must have access to the application paylaod, so as to be able to process the payload and signal the middlebox using the MIDCOM protocol. I.e., the former is a requirement for the latter. Hence the need to distinguish between In-Path and OOP, while limiting the discussion just to the In-path agents. > Are we going to have in-path/out-path and do we > really-care-from-the-point-of view-of-the-MIDCOM-protocol as a discussion > point for the meeting/pub bash in London? The middlebox just takes part in MIDCOM protocol. No diversion function assumed/required on the middlebox. > > regards > > Richard regards, suresh ===== __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 26 21:05:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27165 for ; Thu, 26 Jul 2001 21:05:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10092; Thu, 26 Jul 2001 20:59:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10062 for ; Thu, 26 Jul 2001 20:59:22 -0400 (EDT) Received: from web13806.mail.yahoo.com (web13806.mail.yahoo.com [216.136.175.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26816 for ; Thu, 26 Jul 2001 20:58:20 -0400 (EDT) Message-ID: <20010727005918.48803.qmail@web13806.mail.yahoo.com> Received: from [66.89.112.150] by web13806.mail.yahoo.com; Thu, 26 Jul 2001 17:59:18 PDT Date: Thu, 26 Jul 2001 17:59:18 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [midcom] Comments on Framework 03 draft To: richard.swale@bt.com, midcom@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --- richard.swale@bt.com wrote: > > Richard - The framework cannot be described in a vacuum. The section > > simply talks about the phases in a MIDCOM connection setup. While some > > overlap is inevitable, it is important to note that (a) the > > reader is not > > required to have two documents (i.e., framework and > > requriements document) > > in order to understand this document, (b) the requirements > > and framework > > document should be in sync. > > Unfortuantely this is precisely the reason the requirements should not be in > the framework document - both documents should do one job only. If we > produce a framework document which implies requirements which have been > neither agreed nor aligned with the requirements document we will invariably > have people implementing to assumed and therefore incorrect requirements. > End result will be two solutions, neither of which will interwork > necessarily. > We have had lot of feedback from folks on the list about wording in these sections - 4 (MIDCOm protocol), 6.1(authentication, integrity and confidentiality) and 6.2 (registration and deregistration of MIDCOM agents). Some of the text made it to the draft precisely because of the input from list. There is consensus for the text. I dont see why the requirements would differ from this agreed upon text. Framework and Requirement drafts should move forward independently, without one dragging down the other. It can happen, so long as it is the same forum (ie, the MIDCOM list and ultimately the IESG) that reviews both drafts. regards, suresh __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 26 23:02:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03371 for ; Thu, 26 Jul 2001 23:02:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12432; Thu, 26 Jul 2001 23:03:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12357 for ; Thu, 26 Jul 2001 23:03:11 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03334 for ; Thu, 26 Jul 2001 23:02:10 -0400 (EDT) Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PDZ561A0; Thu, 26 Jul 2001 23:02:39 -0400 Message-Id: <3.0.5.32.20010726224202.00a0a380@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 26 Jul 2001 22:42:02 -0400 To: Pyda Srisuresh , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Framework last call -- level of middlebox intelligence In-Reply-To: <20010722192129.60728.qmail@web13807.mail.yahoo.com> References: <3.0.5.32.20010720153341.0085e990@10.1.1.249> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi Suresh and thanks for your response! I have another round of questions on a few of the issues. I'll put them into separate emails. Here's the first. >> [Mark wrote] >> . The document should make a clear statement on what in a packet the >> middlebox is expected to understand and be able to classify on. I hope >> this is only IP header fields and TCP/UDP port numbers. (Thus the >> middlebox would be "IP-aware" and "TCP/UDP-aware" but not >> "application-aware".) There was the long discussion on the maiiling list >> about being BEEP-aware but I'm not sure what the consensus was (if any). > [Suresh replied] >Application intelligence goes beyond just the TCP/UDP payload. It includes >correlation between sessions, session orientations, port usage and so >forth. The document states in no uncertain terms that the MIDCOM protocol >allows the middlebox to move application intelligence to agents (Ex: refer >the text in sections 2.10 and 4). I dont believe it is necessary to >single out TCP/UDP payload. I think I did not state my point clearly enough. Let me try again. Yes, the document is quite clear that the application intelligence is to be in the agents. What I would like to get clarified is exactly how much "intelligence" needs to remain in the middlebox after that "application" intelligence is moved out. This is fundamentally about where we are drawing the line between the application and the network. It seems clear that the middlebox must be aware of TCP and UDP ports, so that the agent may direct it to give particular treatment (pinholes, NAT translations, etc.) for traffic on particular TCP/UDP ports. For example, the Session-descriptor is described as consisting of direction, source/destination addresses, IP protocol, and source/destination ports. And in section 4 it mentions "port based sessions". Yet there has been discussion on the list (e.g. the recent thread about BEEP) that the middlebox might be expected to look deeper into the packet and give separate treatment to separate threads multiplexed into one port. I am not sure what the consensus was on that. My personal opinion is that the midcom protocol should not ask of the middlebox to look into anything other than the IP, tcp, and udp headers. But in any event we should all come to some agreement on this and place text in the framework document that clearly states the agreed direction. >> [Mark wrote] >> . The document should make a clear statement on what in a packet the >> middlebox may modify. My understanding is this should be only the IP >> header and TCP/UDP port numbers (and associated checksums). The >> requirements draft states this in section 4.1 although it is vague about >> what constitutes the "packet header". My understanding is only the Midcom >> Agent should modify any higher layer information. > [Suresh replied] >Same as above. This is closely related to the issue above. While the above discussion is about what fields the middlebox should be *looking at* to make its decision about a packet, this part of the question is about what fields the middlebox might be expected to modify in processing the packet. Again my personal opinion is that this should be limited to fields within the IP, TCP, and UDP headers but in any event the WG consensus on this should be clearly stated in the framework. -- Thanks, Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 26 23:02:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03381 for ; Thu, 26 Jul 2001 23:02:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12339; Thu, 26 Jul 2001 23:02:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12311 for ; Thu, 26 Jul 2001 23:02:39 -0400 (EDT) Received: from web13802.mail.yahoo.com (web13802.mail.yahoo.com [216.136.175.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03313 for ; Thu, 26 Jul 2001 23:01:37 -0400 (EDT) Message-ID: <20010727030237.56890.qmail@web13802.mail.yahoo.com> Received: from [66.89.112.150] by web13802.mail.yahoo.com; Thu, 26 Jul 2001 20:02:37 PDT Date: Thu, 26 Jul 2001 20:02:37 -0700 (PDT) From: Pyda Srisuresh Subject: Nits (was: RE: [midcom] Comments on Framework 03 draft) To: richard.swale@bt.com, midcom@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --- richard.swale@bt.com wrote: > > > nits > > > === > > > Page 1 and elsewhere. NetMeeting V3.x isn't always a > > peer-peer application > > > so it is a bit misleading to cite it. It can be - but not always. > > > > > I dont know about specific versions. I dont find this misleading. > > Or to be blunt what you have said is factually inaccurate. It is simply an > true statement. > Why is NetMeeting not a peer-to-peer application? Please explain. NetMeeting includes audio/video conferencing, chat, file tarnsfer and so forth. > > > Section 8.6 makes reference to Q.931 which technically > > isn't correct and > > > should probably read H.225.0 call signalling. > > > > > > > Q.931 is the packet format exchanged over H.323 TCP connection. > > The Intel document that describes H.323 also refers the Q.931 > > and H.323 connections interchangeably. So, I suggest, > > we leave this as is. > > > > Sorry - H.323 is an ITU-T specification not an Intel one! H.323 call > signalling is defined in H.225.0 which contains a profile of Q.931 (it uses > the balanced mode of operation). Therefore the call signalling in H.323 is > defined in H.225.0 and not Q.931 - that is a different document and > specification all together. I suggest we change it to make it factually > acurate. > Will do. Thanks. > regards > > Richard > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom ===== __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Jul 26 23:03:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03407 for ; Thu, 26 Jul 2001 23:03:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12393; Thu, 26 Jul 2001 23:03:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12359 for ; Thu, 26 Jul 2001 23:03:11 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03335 for ; Thu, 26 Jul 2001 23:02:10 -0400 (EDT) Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PDZ561BC; Thu, 26 Jul 2001 23:02:39 -0400 Message-Id: <3.0.5.32.20010726225543.00a0a600@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 26 Jul 2001 22:55:43 -0400 To: Pyda Srisuresh , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Framework last call -- middlebox data model In-Reply-To: <20010722192129.60728.qmail@web13807.mail.yahoo.com> References: <3.0.5.32.20010720153341.0085e990@10.1.1.249> Mime-Version: 1.0 Content-Type: text/enriched; 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 Suresh and all, >> [Mark] >> . In 3.0 below the figure it states "The attributes associated with a >> Session-Descriptor may be specific to the individual middlebox function." >> Can you please clarify the meaning of this? What *are* the "attributes"? >> Are they the what-to-do-when-a-packet-matches-this-session-descriptor stuff? >> > [Suresh] >Yes - a variety of Timers, NAT translation parameters etc. Will inlude the >examples. > >> [Mark] >> Section 6.2, "Coupling MIDCOM agents with the middlebox resources requires >> a means of reflecting that into the resource description table of the >> middlebox. In the case of a firewall, for example, the ACL tuple may be >> altered to reflect the optional ALG presence. The revised ACL may look >> something like the following. >> (, , , >> , , , ) >> Can you please clarify this? Aside from the that tuple appears to be >> a specification for identifying a set of packets. I don't see what an ALG >> has to do with that. Besides, isn't it a fundamental concept of midcom >> that the ALG belongs in the agent, not in the middlebox? >> > [Suresh] >This is what registration of an agent/ALG with the middlebox looks like. Let me test my understanding of this. The middlebox maintains a number of "session-descriptors" each of which describes a set of packets that are to be treated in a particular way. The session-descriptor is a tuple roughly of the form (Interface, SessionDirection, SourceAddress, DestinationAddress, Protocol, SourcePort, DestinationPort). Each session descriptor has associated with it some number of actions to be performed by the middlebox. So far there doesn't seem to be a midcom term for these. Let me call them session-actions. I would suppose these actions are things like "open a firewall pinhole", "apply NAT translation y", and perhaps in the future "mark Diffserv codepoint value z". I would further suppose that each session-action has associated with it a timer (possibly) and an identifier of the particular Agent that requested that action. If this view of the world is consistent with that of others in the wg, I would suggest that describing the middlebox function in terms of an abstract data model like that would help to clarify the framework. I'd be willing to propose some text if there is interest in this. --Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Jul 27 09:36:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17225 for ; Fri, 27 Jul 2001 09:36:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05250; Fri, 27 Jul 2001 09:35:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05217 for ; Fri, 27 Jul 2001 09:35:42 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17148 for ; Fri, 27 Jul 2001 09:34:43 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6RDZOT15158 for ; Fri, 27 Jul 2001 06:35:24 -0700 (PDT) Received: from cisco.com (sjc-vpn2-159.cisco.com [10.21.112.159]) by airborne.cisco.com (Mirapoint) with SMTP id AHT14292; Fri, 27 Jul 2001 06:35:09 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Fri, 27 Jul 2001 09:35:10 -0400 Date: Fri, 27 Jul 2001 09:35:10 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Document formatting Message-ID: <20010727093509.A1692@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <5.1.0.14.0.20010726110851.00a24390@mira-sjc5-4.cisco.com> <0e9601c1161c$5c183430$8753cf3f@FATORA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0e9601c1161c$5c183430$8753cf3f@FATORA>; from mrose+mtr.netnews@dbc.mtview.ca.us on Thu, Jul 26, 2001 at 02:45:59PM -0700 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Thu, Jul 26, 2001 at 02:45:59PM -0700, Marshall T. Rose wrote: > author in xml and produce .txt (rfc/i-d), html, and nroff... c.f., rfc 2629 > and http://xml.resource.org/ I really like the xml2rfc package, as far as it goes. There are a number of things I can't do -- case in point: have multiple sets of custom indented paragraph "bullets", like "F1:", where the number auto-increments globally even though sets of these bullets are interspersed with other, normal paragraphs. If xml2rfc could be extended to do this sort of thing I'd be very happy. Even just a "list continuation" style -- a non-bulleted paragraph indented to the same depth as the body text of a bulleted paragraph above it -- would be nice. Otherwise I revert to nroff. How many hours would it take me to learn how to add such extensions? :-) Thanks ... Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat Jul 28 20:42:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12254 for ; Sat, 28 Jul 2001 20:42:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22991; Sat, 28 Jul 2001 20:37:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22963 for ; Sat, 28 Jul 2001 20:37:16 -0400 (EDT) Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11406 for ; Sat, 28 Jul 2001 20:36:17 -0400 (EDT) From: richard.swale@bt.com Received: from cbtlipnt01.btlabs.bt.co.uk by gandalf (local) with ESMTP; Sat, 28 Jul 2001 21:42:38 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Sat, 28 Jul 2001 21:42:38 +0100 Message-ID: To: srisuresh@yahoo.com, richard.swale@bt.com, midcom@ietf.org Subject: RE: Nits (was: RE: [midcom] Comments on Framework 03 draft) Date: Sat, 28 Jul 2001 21:41:42 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Suresh, > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > Sent: 27 July 2001 04:03 > To: richard.swale@bt.com; midcom@ietf.org > Subject: Nits (was: RE: [midcom] Comments on Framework 03 draft) > > > > --- richard.swale@bt.com wrote: > > > > nits > > > > === > > > > Page 1 and elsewhere. NetMeeting V3.x isn't always a > > > peer-peer application > > > > so it is a bit misleading to cite it. It can be - but > not always. > > > > > > > I dont know about specific versions. I dont find this misleading. > > > > Or to be blunt what you have said is factually inaccurate. > It is simply an > > true statement. > > > > Why is NetMeeting not a peer-to-peer application? Please explain. > NetMeeting includes audio/video conferencing, chat, file tarnsfer > and so forth. > Just because NetMeeting includes or can include some traditional peer-peer applications doesn't mean it is a peer-peer application itself. The text in question suggested that NetMeeting was a peer-peer application. However in gatekeeper routed mode, or indeed if it uses a gateway, it clearly isn't a pure peer-peer application; there is a whole lot of stuff in between the two end-points. In gatekeeper mode, some of the signalling is communicated via the gatekeeper and so does not go directly to the called terminal - there is no guarantee that what NetMeeting sends out is what gets to the far side. In gateway mode, the call hits a gateway which translates the signalling and media - so is not peer-to-peer. Hope this helps. regards Richard > > > > Section 8.6 makes reference to Q.931 which technically > > > isn't correct and > > > > should probably read H.225.0 call signalling. > > > > > > > > > > Q.931 is the packet format exchanged over H.323 TCP connection. > > > The Intel document that describes H.323 also refers the Q.931 > > > and H.323 connections interchangeably. So, I suggest, > > > we leave this as is. > > > > > > > Sorry - H.323 is an ITU-T specification not an Intel one! H.323 call > > signalling is defined in H.225.0 which contains a profile > of Q.931 (it uses > > the balanced mode of operation). Therefore the call > signalling in H.323 is > > defined in H.225.0 and not Q.931 - that is a different document and > > specification all together. I suggest we change it to make > it factually > > acurate. > > > Will do. Thanks. > > > regards > > > > Richard > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www.ietf.org/mailman/listinfo/midcom > > > ===== > > > __________________________________________________ > Do You Yahoo!? > Make international calls for as low as $.04/minute with > Yahoo! Messenger > http://phonecard.yahoo.com/ > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 30 10:42:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25055 for ; Mon, 30 Jul 2001 10:42:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22568; Mon, 30 Jul 2001 10:24:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22539 for ; Mon, 30 Jul 2001 10:24:41 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23876 for ; Mon, 30 Jul 2001 10:23:42 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AD991053023A; Mon, 30 Jul 2001 10:22:17 -0400 Message-ID: <005f01c11903$4e2db860$2300000a@acmepacket.com> From: "Bob Penfield" To: References: <3.0.5.32.20010720153341.0085e990@10.1.1.249> Subject: [midcom] Framework comments & suggestions Date: Mon, 30 Jul 2001 10:24:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I have several comments on the framework document, mostly minor issues. Section 2.6 states that "ALGs are not visible to end-hosts". I don't think that this is necessarily true. If fact, since OOP agents are out for now, the MIDCOM framework requires that the ALG functionality be embedded either in a proxy or an end-host (or other entity that is in-path) instead of in the middlebox as it is today. Based on this definition, an ALG cannot be a MIDCOM agent since it is not "naturally in the message path". I suggest the following wording: Traditional ALGs are embedded in a middlebox and are not visible to end-hosts, unlike the proxies which are relay agents terminating sessions with both end-hosts. Most ALGs do not terminate session with either end-host. ALGs examine and optionally modify application payload content to facilitate the flow of application traffic through a middlebox. ALGs are middlebox centric, in that they assist the middleboxes in carrying out their function. Whereas, the proxies act as focal point for application servers, relaying traffic between application clients and servers. The MIDCOM framework will allow for ALG functionality to be embedded in proxies and end-points external to the middlebox and closer to the application intelligence. The last paragraph in 2.6 can be eliminated. In section 2.8, I suggest the following wording to clarify the difference between an in-path and out-of-path agent. The MIDCOM framework is specifically designed for applications that consist of signaling/control sessions and media/data sessions. These control and data flows may traverse different paths through the network. In order to perform the ALG function, MIDCOM agents must access the control messages. This document considers only MIDCOM agents co-resident on devices that are naturally in the control message path of an application. These are also referred to as "In-Path MIDCOM agents". This may be an application proxy, gateway, or in the extreme case, one of the end-hosts, that is party to the application. Agents not resident on entities that are natively in the path of application flows are referred to as Out-of-Path (OOP) agents. These require that control messages be diverted from their natural path to the agents and then reinjected into the path. OOP agents will be considered out of scope for this document. As such, there will be no further discussion on OOP agents in the reminder of this document. In section 5.0, it says: In-Path MIDCOM agents are entities that have a native role in the path of the application traversal (with prior knowledge to one of the application end-hosts) ... The application end-hosts do not necessarily have "prior knowledge" of all the proxies in the path of application traversal. When there is more than one proxy in the path, the application end-hosts will have prior knowledge of their adjacent proxy, but not of the other intervening proxies, one of which may be a MIDCOM agent. I suggest removing the comment inside the parenthesis. In Figure 2, the control paths for the RTSP and SIP are missing from the right side of the firewall. In section 6.0, it says: The Policy server does not assist a middlebox in the implementation of the services it provides or with resource authorization on the middlebox Why not? Why should MIDCOM impose a restriction what a middlebox and its policy server can do? What role a policy server plays beyond the registration and authorization of agents is beyond the scope of MIDCOM and we should not attempt to describe what is does or does not do. This sentence should be removed. In the last paragraph of 6.2, change "deregister" to "disconnect" in the first sentence. The labeling in Figure 3 is not correct. It should look like this: _________ --->| SIP |<-----\ / | Proxy | \ | |_________| | 1| | ^ ^ | 4| | | | 7| |6 | |8 2| |3 | | |5 ______________ | | | | | | _____________ | |<-/ _v_|__|_v__ \->| | | External | Na | | Nc | SIP Phone | | SIP phone |>------->| MiddleBox |>------>| within | | |<-------<|___________|<------<| Pvt. domain| |____________| Nb Nd |____________| Where 1&4 are the INVITE message. 5&8 are the 200-OK response. 2&3 are the setup of the flow Nd+Nb and 6&7 are the setup for the flow Na+Nc. In the timeline flows in 7.1, 7.2, and 7.3, the 100Trying should be immediately after the INVITE is received by the proxy. It tells the client that the request has been received and prevents the client from retransmitting the INVITE. There is no need to wait for the results of the first NAT/Firewall setup. In the timeline flow in 7.2, modification of IP addresses in the SIP headers needs to occur for the INVITE in the same manner as the ACK and the BYE. This would also have to be done for the responses coming back from the private phone. Also, I believe the source address needs to be NATd in the 180Ringing and 200-OK responses from the private phone. The timeline flow in 7.3 indicates the BYE and its response have SDP payload which they do not. For each request and response, the proxy needs to modify IP addresses in the SIP headers (same as in 7.2). (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 30 11:16:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27256 for ; Mon, 30 Jul 2001 11:15:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23999; Mon, 30 Jul 2001 11:15:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23968 for ; Mon, 30 Jul 2001 11:15:20 -0400 (EDT) Received: from web13807.mail.yahoo.com (web13807.mail.yahoo.com [216.136.175.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27121 for ; Mon, 30 Jul 2001 11:14:19 -0400 (EDT) Message-ID: <20010730151517.41702.qmail@web13807.mail.yahoo.com> Received: from [65.12.33.187] by web13807.mail.yahoo.com; Mon, 30 Jul 2001 08:15:17 PDT Date: Mon, 30 Jul 2001 08:15:17 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Framework last call -- middlebox data model To: Mark Duffy , midcom@ietf.org In-Reply-To: <3.0.5.32.20010723152522.0093f100@10.1.1.249> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Mark, It has been a non-goal of the Work group to describe data models within middlebox. As such, the FW draft had purposely stayed away from going into guts of the middlebox. Hope you understand. Thanks. cheers, suresh --- Mark Duffy wrote: > Hi Suresh and all, > > >> [Mark] > >> . In 3.0 below the figure it states "The attributes associated with a > >> Session-Descriptor may be specific to the individual middlebox function." > >> Can you please clarify the meaning of this? What *are* the "attributes"? > >> Are they the what-to-do-when-a-packet-matches-this-session-descriptor > stuff? > >> > > [Suresh] > >Yes - a variety of Timers, NAT translation parameters etc. Will inlude the > >examples. > > > > >> [Mark] > >> Section 6.2, "Coupling MIDCOM agents with the middlebox resources requires > >> a means of reflecting that into the resource description table of the > >> middlebox. In the case of a firewall, for example, the ACL tuple may be > >> altered to reflect the optional ALG presence. The revised ACL may look > >> something like the following. > >> (, , , > >> , , , ) > >> Can you please clarify this? Aside from the that tuple appears to > be > >> a specification for identifying a set of packets. I don't see what an ALG > >> has to do with that. Besides, isn't it a fundamental concept of midcom > >> that the ALG belongs in the agent, not in the middlebox? > >> > > [Suresh] > >This is what registration of an agent/ALG with the middlebox looks like. > > > Let me test my understanding of this. > > The middlebox maintains a number of "session-descriptors" each of which > describes a set of packets that are to be treated in a particular way. The > session-descriptor is a tuple roughly of the form (Interface, > SessionDirection, SourceAddress, DestinationAddress, Protocol, SourcePort, > DestinationPort). > > Each session descriptor has associated with it some number of actions to be > performed by the middlebox. So far there doesn't seem to be a midcom term > for these. Let me call them session-actions. I would suppose these > actions are things like "open a firewall pinhole", "apply NAT translation > y", and perhaps in the future "mark Diffserv codepoint value z". > > I would further suppose that each session-action has associated with it a > timer (possibly) and an identifier of the particular Agent that requested > that action. > > If this view of the world is consistent with that of others in the wg, I > would suggest that describing the middlebox function in terms of an > abstract data model like that would help to clarify the framework. I'd be > willing to propose some text if there is interest in this. > > --Mark > > ===== __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 30 11:22:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27803 for ; Mon, 30 Jul 2001 11:22:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24226; Mon, 30 Jul 2001 11:21:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24198 for ; Mon, 30 Jul 2001 11:21:33 -0400 (EDT) Received: from web13801.mail.yahoo.com (web13801.mail.yahoo.com [216.136.175.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27678 for ; Mon, 30 Jul 2001 11:20:32 -0400 (EDT) Message-ID: <20010730152130.56387.qmail@web13801.mail.yahoo.com> Received: from [65.12.33.187] by web13801.mail.yahoo.com; Mon, 30 Jul 2001 08:21:30 PDT Date: Mon, 30 Jul 2001 08:21:30 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Framework last call -- level of middlebox intelligence To: Melinda Shore , Mark Duffy , midcom@ietf.org In-Reply-To: <5.1.0.14.0.20010723184530.00a28760@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 As such, middleboxes that understand the transporty headers (ex: TCP, UDP and SCTP?) has been the focus of this WG. I can certainly state this in the document. Anything beyond the transport headers will be assumed to require application-specific intelligence. Thanks. cheers, suresh --- Melinda Shore wrote: > At 04:53 PM 7/23/01 -0400, Mark Duffy wrote: > >Why am I looking for this? Because without stating this we in fact have > >very little. It doesn't mean much to say midcom allows moving the > >"application" intelligence from the middlebox to the midcom agent if one > >does not define where the "applications" begin. No? > > That's an excellent point. We (the collective "we" - there's > certainly been some disagreement, however) have been assuming > that we're dealing with transport-layer middleboxes and there > seems to be some consensus around having us not skip past the > transport (TCP, UDP, SCTP) headers. We must stay mindful, > however, of the possibility that either future iterations or > vendor-proprietary extensions will want to go deeper into the > packet, and must therefore require that the protocol be > sufficiently expressive to allow something beyond {address, > port, proto}. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom ===== __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 30 12:03:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01421 for ; Mon, 30 Jul 2001 12:03:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26108; Mon, 30 Jul 2001 12:03:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26077 for ; Mon, 30 Jul 2001 12:03:53 -0400 (EDT) Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01353 for ; Mon, 30 Jul 2001 12:02:52 -0400 (EDT) From: richard.swale@bt.com Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Mon, 30 Jul 2001 17:02:28 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Mon, 30 Jul 2001 17:01:43 +0100 Message-ID: To: srisuresh@yahoo.com, mshore@cisco.com, mduffy@quarrytech.com, midcom@ietf.org Subject: RE: [midcom] Framework last call -- level of middlebox intellig ence Date: Mon, 30 Jul 2001 17:01:27 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Sounds like straying into the details of the requirements document. I suggest we put this text there and not in the Framework document. regards Richard > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > Sent: 30 July 2001 16:22 > To: Melinda Shore; Mark Duffy; midcom@ietf.org > Subject: Re: [midcom] Framework last call -- level of middlebox > intelligence > > > As such, middleboxes that understand the transporty headers > (ex: TCP, UDP and SCTP?) has been the focus of this WG. > I can certainly state this in the document. Anything beyond > the transport headers will be assumed to require > application-specific intelligence. Thanks. > > cheers, > suresh > > --- Melinda Shore wrote: > > At 04:53 PM 7/23/01 -0400, Mark Duffy wrote: > > >Why am I looking for this? Because without stating this > we in fact have > > >very little. It doesn't mean much to say midcom allows moving the > > >"application" intelligence from the middlebox to the > midcom agent if one > > >does not define where the "applications" begin. No? > > > > That's an excellent point. We (the collective "we" - there's > > certainly been some disagreement, however) have been assuming > > that we're dealing with transport-layer middleboxes and there > > seems to be some consensus around having us not skip past the > > transport (TCP, UDP, SCTP) headers. We must stay mindful, > > however, of the possibility that either future iterations or > > vendor-proprietary extensions will want to go deeper into the > > packet, and must therefore require that the protocol be > > sufficiently expressive to allow something beyond {address, > > port, proto}. > > > > Melinda > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www.ietf.org/mailman/listinfo/midcom > > > ===== > > > __________________________________________________ > Do You Yahoo!? > Make international calls for as low as $.04/minute with > Yahoo! Messenger > http://phonecard.yahoo.com/ > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 30 12:26:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03568 for ; Mon, 30 Jul 2001 12:26:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26691; Mon, 30 Jul 2001 12:25:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26660 for ; Mon, 30 Jul 2001 12:25:02 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03366 for ; Mon, 30 Jul 2001 12:24:00 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6UGOe309653 for ; Mon, 30 Jul 2001 09:24:40 -0700 (PDT) Received: from cisco.com (sjc-vpn2-152.cisco.com [10.21.112.152]) by airborne.cisco.com (Mirapoint) with SMTP id AID00848; Mon, 30 Jul 2001 09:24:28 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Mon, 30 Jul 2001 12:24:30 -0400 Date: Mon, 30 Jul 2001 12:24:29 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Framework last call -- level of middlebox intellig ence Message-ID: <20010730122429.D1532@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from richard.swale@bt.com on Mon, Jul 30, 2001 at 05:01:27PM +0100 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org We continue to run into this issue of how much "framework" to put in requirements draft, and how much "requirement" to put in the framework draft. The process is iterative -- each builds on the other. Requirements are the most sensitive, I think. Therefore I suggest that any time the framework editors want to make an assumption about any requirement in the framework draft, they put it in with something which clearly marks it as an assumption (e.g. ">>ASSUMPTION<<"), and ask explicitly on the list and get consensus on it. When the requirements draft editors feel a need for context, I suggest that that context be added, but that it be moved to the framework draft as soon as possible. My ideal would be for the requirements editors to feel comfortable just referring to the framework for all context, and for every assumption in the framework draft to be brought out explicitly in the requirements. In this particular case, I believe we already have consensus that middlebox packet manipulation will stick to the transport layer headers and below (I mean, what's the point of this WG otherwise?). Therefore the next step is for that statement to go into the framework draft. Lo and behold, we have: "However the Middlebox must not alter packet information unless it appears in the packet header. This is to ensure that there is an appropriate separation of concerns between the MIDCOM Agent and the Middlebox." All we have to do is get explicit agreement on what "packet header" means, perhaps tweak the text, and we have alignment. I think "packet header" should be changed to "IP and transport headers". Secondarily, I would also like to see this requirement made more visible. imho ... Scott On Mon, Jul 30, 2001 at 05:01:27PM +0100, richard.swale@bt.com wrote: > Sounds like straying into the details of the requirements document. I > suggest we put this text there and not in the Framework document. > > regards > > Richard > > > -----Original Message----- > > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > > Sent: 30 July 2001 16:22 > > To: Melinda Shore; Mark Duffy; midcom@ietf.org > > Subject: Re: [midcom] Framework last call -- level of middlebox > > intelligence > > > > > > As such, middleboxes that understand the transporty headers > > (ex: TCP, UDP and SCTP?) has been the focus of this WG. > > I can certainly state this in the document. Anything beyond > > the transport headers will be assumed to require > > application-specific intelligence. Thanks. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 30 13:04:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07007 for ; Mon, 30 Jul 2001 13:04:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28044; Mon, 30 Jul 2001 13:03:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28019 for ; Mon, 30 Jul 2001 13:03:30 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06840 for ; Mon, 30 Jul 2001 13:02:28 -0400 (EDT) Received: from MDUFFY ([10.1.3.98]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PDZ56H78; Mon, 30 Jul 2001 13:02:56 -0400 Message-Id: <3.0.5.32.20010730130112.0086aea0@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 30 Jul 2001 13:01:12 -0400 To: Pyda Srisuresh , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Framework last call -- middlebox data model In-Reply-To: <20010730151517.41702.qmail@web13807.mail.yahoo.com> References: <3.0.5.32.20010723152522.0093f100@10.1.1.249> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Suresh, that it fine. I am not hung up on a data model. What I was really looking for was more specific description around the concept of the agent using the midcom protocol to convey to the middlebox WHICH packets to do something with, and WHAT to do with them. I think the WHICH is pretty much covered by the session-descriptor concept introduced in section 3.0. But there is really not much specific in the document about the WHAT, that is, what actions does the midcom protocol allow for specifying. (What I have called session-actions in the message below.) Associated with that may be other miscellaneous directives such as HOW LONG to do the action for. I believe you indicated in an earlier email you would add more examples of the WHAT. I was thinking in terms of something more definitive than examples, but perhaps this is really an issue for the protocol requirements draft. -Mark At 08:15 AM 7/30/01 -0700, Pyda Srisuresh wrote: >Mark, > >It has been a non-goal of the Work group to describe data models >within middlebox. As such, the FW draft had purposely stayed away >from going into guts of the middlebox. Hope you understand. Thanks. > >cheers, >suresh > >--- Mark Duffy wrote: [snip] >> Let me test my understanding of this. >> >> The middlebox maintains a number of "session-descriptors" each of which >> describes a set of packets that are to be treated in a particular way. The >> session-descriptor is a tuple roughly of the form (Interface, >> SessionDirection, SourceAddress, DestinationAddress, Protocol, SourcePort, >> DestinationPort). >> >> Each session descriptor has associated with it some number of actions to be >> performed by the middlebox. So far there doesn't seem to be a midcom term >> for these. Let me call them session-actions. I would suppose these >> actions are things like "open a firewall pinhole", "apply NAT translation >> y", and perhaps in the future "mark Diffserv codepoint value z". >> >> I would further suppose that each session-action has associated with it a >> timer (possibly) and an identifier of the particular Agent that requested >> that action. >> >> If this view of the world is consistent with that of others in the wg, I >> would suggest that describing the middlebox function in terms of an >> abstract data model like that would help to clarify the framework. I'd be >> willing to propose some text if there is interest in this. >> >> --Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 30 13:19:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08289 for ; Mon, 30 Jul 2001 13:19:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28223; Mon, 30 Jul 2001 13:19:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28194 for ; Mon, 30 Jul 2001 13:19:05 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08169 for ; Mon, 30 Jul 2001 13:18:06 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6UHGiJ24619 for ; Mon, 30 Jul 2001 10:16:45 -0700 (PDT) Received: from cisco.com (sjc-vpn2-152.cisco.com [10.21.112.152]) by airborne.cisco.com (Mirapoint) with SMTP id AID01891; Mon, 30 Jul 2001 10:18:14 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Mon, 30 Jul 2001 13:18:16 -0400 Date: Mon, 30 Jul 2001 13:18:16 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Framework last call -- middlebox data model Message-ID: <20010730131815.I1532@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <3.0.5.32.20010723152522.0093f100@10.1.1.249> <20010730151517.41702.qmail@web13807.mail.yahoo.com> <3.0.5.32.20010730130112.0086aea0@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3.0.5.32.20010730130112.0086aea0@email.quarrytech.com>; from mduffy@quarrytech.com on Mon, Jul 30, 2001 at 01:01:12PM -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Mon, Jul 30, 2001 at 01:01:12PM -0400, Mark Duffy wrote: > Suresh, that it fine. I am not hung up on a data model. What I was really > looking for was more specific description around the concept of the agent > using the midcom protocol to convey to the middlebox WHICH packets to do > something with, and WHAT to do with them. > > I think the WHICH is pretty much covered by the session-descriptor concept > introduced in section 3.0. But there is really not much specific in the > document about the WHAT, that is, what actions does the midcom protocol > allow for specifying. (What I have called session-actions in the message > below.) Associated with that may be other miscellaneous directives such as > HOW LONG to do the action for. > > I believe you indicated in an earlier email you would add more examples of > the WHAT. I was thinking in terms of something more definitive than > examples, but perhaps this is really an issue for the protocol requirements > draft. > > -Mark Mark, I think the strategy for this WG is that the framework says HOW, while the requirements draft says how to say WHICH and WHAT, and by implication which whiches and whats you can say. So you're looking in the wrong draft. If you want anything besides HOW, get it in the requirements draft. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 30 22:04:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA09272 for ; Mon, 30 Jul 2001 22:04:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11127; Mon, 30 Jul 2001 21:54:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11096 for ; Mon, 30 Jul 2001 21:54:51 -0400 (EDT) Received: from web13803.mail.yahoo.com (web13803.mail.yahoo.com [216.136.175.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08641 for ; Mon, 30 Jul 2001 21:53:49 -0400 (EDT) Message-ID: <20010731015448.20780.qmail@web13803.mail.yahoo.com> Received: from [66.89.112.150] by web13803.mail.yahoo.com; Mon, 30 Jul 2001 18:54:48 PDT Date: Mon, 30 Jul 2001 18:54:48 -0700 (PDT) From: Pyda Srisuresh Subject: RE: Nits (was: RE: [midcom] Comments on Framework 03 draft) To: richard.swale@bt.com, midcom@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --- richard.swale@bt.com wrote: <... stuff deleted> > > > > Why is NetMeeting not a peer-to-peer application? Please explain. > > NetMeeting includes audio/video conferencing, chat, file tarnsfer > > and so forth. > > > > Just because NetMeeting includes or can include some traditional peer-peer > applications doesn't mean it is a peer-peer application itself. The text in > question suggested that NetMeeting was a peer-peer application. However in > gatekeeper routed mode, or indeed if it uses a gateway, it clearly isn't a > pure peer-peer application; there is a whole lot of stuff in between the two > end-points. In gatekeeper mode, some of the signalling is communicated via > the gatekeeper and so does not go directly to the called terminal - there is > no guarantee that what NetMeeting sends out is what gets to the far side. In > gateway mode, the call hits a gateway which translates the signalling and > media - so is not peer-to-peer. Hmm... the semantics I ascribe to peer-to-peer is from the perspective of end-user and is different from what you seem to imply. Correct me if I misunderstood. But, you seem to imply that an application is peer-to-peer only when there is direct communication between end-hosts with no third party intervention. NetMeeting may use Gatekeeper to route calls and to transit data. So, by your definition, this does not fit the definition of peer-to-peer. I dont believe, most people interprest peer-to-peer that way. Certainly, I dont think Christian implied this when he first suggested including this in the text. My understanding of peer-to-peer is simply that either party can initiate a connection to the other. For example, Telnet and HTTP browsers would clearly be considered client-server type applications. Video conferencing and Phone calls and chat will be considered peer-to-peer (unless incoming calls are disabled). This does not necessarily refer to how a particular application is implemented. > > Hope this helps. > > regards > > Richard Thanks. regards, suresh ===== __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Jul 30 23:40:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14717 for ; Mon, 30 Jul 2001 23:40:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13285; Mon, 30 Jul 2001 23:39:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13257 for ; Mon, 30 Jul 2001 23:39:28 -0400 (EDT) Received: from web13803.mail.yahoo.com (web13803.mail.yahoo.com [216.136.175.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14648 for ; Mon, 30 Jul 2001 23:38:26 -0400 (EDT) Message-ID: <20010731033924.3097.qmail@web13803.mail.yahoo.com> Received: from [65.12.33.187] by web13803.mail.yahoo.com; Mon, 30 Jul 2001 20:39:24 PDT Date: Mon, 30 Jul 2001 20:39:24 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] framework comments To: Eliot Lear Cc: midcom@ietf.org In-Reply-To: <3B6099F3.2020402@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 --- Eliot Lear wrote: > 2.3 Definition of Firewall > > "packet filtering" is but one type of firewall. We should borrow a > better definition from elsewhere. > Eliot - There may be many variations to the theme, all eventually boiling down to packet permitting/filtering. The purpose was merely to expose this aspect of the firewall from middlebox function perspective. As I recall, there were multiple semantics associated with the term, at the time the discussion got started on the list. Some implying NAT function and IPsec Gateway function and so forth - all included in the same term. I believe, the current definition will suffie for the purposes of MIDCOM FW. > Figure 3 - you skipped or removed step "5". > OK. > I'm also interested in changing some wording to the protocol > requirements, and a more general statement about protocol layering. Bob > Braden's recent post to the IETF I think is most concerning. > Not sure what you are talkig about. I didnt see the e-mail from Bob Braden. Were you going to suggest somethign specific to framework draft? > It is necessary for authorization to occur within the midcom protocol. > The conditions of that authorization may be based on characteristics > taken from any part of the protocol stack. That is the nature of > policy. However, the communication that is authorized is a > TCP/UDP/SCTP/etc. tuple. > > The way these decisions are made may require the midcom agent to pass to > the middlebox opaque application level information that it MAY in turn > pass onto an appropriate policy server. This information does need to > be structured and supported by the protocol, and may even be multiple > blocks that are passed to different policy servers. Consider a policy > server that handles voice, allowing voice sessions of < 64 kb/s for > lengths of time <= 4 hours, but a separate policy server that restricts > communications with my competitors and stock broker ;-) > We discussed this before on ths list. We agreed that the only policy server this WG will look into is the policy server authorizng the agents. Any application or user specific policy decisions are considered out of bounds for this WG. (Refer last paragraph in section 2.9). > I want to be able to make some statement about "no gnutella files of > type mpg or avi, but allow mp3" or not. > Thanks. regards, suresh __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 31 00:22:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16378 for ; Tue, 31 Jul 2001 00:22:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14076; Tue, 31 Jul 2001 00:22:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14047 for ; Tue, 31 Jul 2001 00:22:27 -0400 (EDT) Received: from web13807.mail.yahoo.com (web13807.mail.yahoo.com [216.136.175.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16302 for ; Tue, 31 Jul 2001 00:21:23 -0400 (EDT) Message-ID: <20010731042222.81809.qmail@web13807.mail.yahoo.com> Received: from [65.12.33.187] by web13807.mail.yahoo.com; Mon, 30 Jul 2001 21:22:22 PDT Date: Mon, 30 Jul 2001 21:22:22 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Framework comments & suggestions To: Bob Penfield , midcom@ietf.org In-Reply-To: <005f01c11903$4e2db860$2300000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --- Bob Penfield wrote: > I have several comments on the framework document, mostly minor issues. > > Section 2.6 states that "ALGs are not visible to end-hosts". I don't think > that this is necessarily true. If fact, since OOP agents are out for now, > the MIDCOM framework requires that the ALG functionality be embedded either > in a proxy or an end-host (or other entity that is in-path) instead of in > the middlebox as it is today. Based on this definition, an ALG cannot be a > MIDCOM agent since it is not "naturally in the message path". I suggest the Just because an ALG is in the natural path of an application, that does not mean that the agent should be visible to end-hosts. I dont see how the ALG definition conflicts with the In-Path MIDCOM agent. > following wording: > > Traditional ALGs are embedded in a middlebox and are not visible to > end-hosts, unlike the proxies which are relay agents terminating > sessions with both end-hosts. Most ALGs do not terminate session with > either end-host. ALGs examine and optionally modify > application payload content to facilitate the flow of application > traffic through a middlebox. ALGs are middlebox centric, in that > they assist the middleboxes in carrying out their function. > Whereas, the proxies act as focal point for application servers, > relaying traffic between application clients and servers. The MIDCOM > framework will allow for ALG functionality to be embedded in proxies > and end-points external to the middlebox and closer to the application > intelligence. > > The last paragraph in 2.6 can be eliminated. > > In section 2.8, I suggest the following wording to clarify the difference > between an in-path and out-of-path agent. > > The MIDCOM framework is specifically designed for applications > that consist of signaling/control sessions and media/data > sessions. These control and data flows may traverse > different paths through the network. In order to perform the > ALG function, MIDCOM agents must access the control messages. > This document considers only MIDCOM agents co-resident on > devices that are naturally in the control message path > of an application. These are also referred to as "In-Path MIDCOM agents". > This may be an application proxy, gateway, or in the extreme case, > one of the end-hosts, that is party to the application. > > Agents not resident on entities that are natively in the path of > application flows are referred to as Out-of-Path (OOP) agents. These > require that control messages be diverted from their natural path to > the agents and then reinjected into the path. OOP agents will be > considered out of scope for this document. As such, there will > be no further discussion on OOP agents in the reminder of this > document. > Bob - this portion of the text went through multiple edits. I really dont want to change the text unless absolutely necessary. Why go into the details of diversion function for OOP agents, when the WG does not want to pursue that discussion. That will simply raise additional questions - all in an area the WG is queasy about. So, my druthers is to leave the text as is. Hope you understand. Thanks. > In section 5.0, it says: > > In-Path MIDCOM agents are entities that have a native role in the > path of the application traversal (with prior knowledge to one of > the application end-hosts) ... > > The application end-hosts do not necessarily have "prior knowledge" of all > the proxies in the path of application traversal. When there is more than > one proxy in the path, the application end-hosts will have prior knowledge > of their adjacent proxy, but not of the other intervening proxies, one of > which may be a MIDCOM agent. I suggest removing the comment inside the > parenthesis. > Done. > In Figure 2, the control paths for the RTSP and SIP are missing from the > right side of the firewall. > OK. I will add 2 lines. > In section 6.0, it says: > > The Policy server does not assist a > middlebox in the implementation of the services it provides or > with resource authorization on the middlebox > > Why not? Why should MIDCOM impose a restriction what a middlebox and its > policy server can do? What role a policy server plays beyond the > registration and authorization of agents is beyond the scope of MIDCOM and > we should not attempt to describe what is does or does not do. This sentence > should be removed. > The sentence is there to state what the policy server cannot be expected to do. Hope the following rewording will work for you. The Policy server is not intended to assist middlebox in the implementation of the services it provides or with resource authorization on the middlebox. > In the last paragraph of 6.2, change "deregister" to "disconnect" in the > first sentence. > Done. > The labeling in Figure 3 is not correct. It should look like this: > > _________ > --->| SIP |<-----\ > / | Proxy | \ > | |_________| | > 1| | ^ ^ | 4| > | | | 7| |6 | > |8 2| |3 | | |5 > ______________ | | | | | | _____________ > | |<-/ _v_|__|_v__ \->| | > | External | Na | | Nc | SIP Phone | > | SIP phone |>------->| MiddleBox |>------>| within | > | |<-------<|___________|<------<| Pvt. domain| > |____________| Nb Nd |____________| > > I will respond to this on a different thread. Thanks. regards, suresh ===== __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 31 02:22:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05307 for ; Tue, 31 Jul 2001 02:22:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25259; Tue, 31 Jul 2001 02:18:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25228 for ; Tue, 31 Jul 2001 02:18:39 -0400 (EDT) Received: from obsoft.com (sdsl-208-185-238-35.dsl.sjc.megapath.net [208.185.238.35]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04743 for ; Tue, 31 Jul 2001 02:17:36 -0400 (EDT) Received: from obsoft.com (IDENT:sardana@localhost.localdomain [127.0.0.1]) by obsoft.com (8.9.3/8.9.3) with ESMTP id XAA08801; Mon, 30 Jul 2001 23:23:17 -0700 Message-ID: <3B664ED5.ACD0ABF2@obsoft.com> Date: Mon, 30 Jul 2001 23:23:17 -0700 From: Bobby Sardana Organization: ObjectSoftware, Inc X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Pyda Srisuresh CC: richard.swale@bt.com, midcom@ietf.org Subject: Re: Nits (was: RE: [midcom] Comments on Framework 03 draft) References: <20010731015448.20780.qmail@web13803.mail.yahoo.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 Greetings all: I do agree with the definition of peer-to-peer that Richard has provided. There can't be two defintions, one which applies to end-user perception and the other when end systems are communicating without an intermediate node. If an intermediate node is involved and performs routing, gatekeeping activities, it can maintain the state of each communicating end nodes. The communication of the end nodes is then via an intermediary and not peer-to-peer. OTOH, if there is no intermediary involved and the end nodes communicate and maintain the state, the application is peer-to-peer. Bobby [0.02c :-] Sardana. sardana@obsoft.com Pyda Srisuresh wrote: > --- richard.swale@bt.com wrote: > <... stuff deleted> > > > > > > Why is NetMeeting not a peer-to-peer application? Please explain. > > > NetMeeting includes audio/video conferencing, chat, file tarnsfer > > > and so forth. > > > > > > > Just because NetMeeting includes or can include some traditional peer-peer > > applications doesn't mean it is a peer-peer application itself. The text in > > question suggested that NetMeeting was a peer-peer application. However in > > gatekeeper routed mode, or indeed if it uses a gateway, it clearly isn't a > > pure peer-peer application; there is a whole lot of stuff in between the two > > end-points. In gatekeeper mode, some of the signalling is communicated via > > the gatekeeper and so does not go directly to the called terminal - there is > > no guarantee that what NetMeeting sends out is what gets to the far side. In > > gateway mode, the call hits a gateway which translates the signalling and > > media - so is not peer-to-peer. > > Hmm... the semantics I ascribe to peer-to-peer is from the perspective of > end-user and is different from what you seem to imply. Correct me if I > misunderstood. But, you seem to imply that an application is peer-to-peer > only when there is direct communication between end-hosts with no third > party intervention. NetMeeting may use Gatekeeper to route calls and to > transit data. So, by your definition, this does not fit the definition > of peer-to-peer. > > I dont believe, most people interprest peer-to-peer that way. Certainly, > I dont think Christian implied this when he first suggested including > this in the text. My understanding of peer-to-peer is simply that either > party can initiate a connection to the other. For example, Telnet and HTTP > browsers would clearly be considered client-server type applications. > Video conferencing and Phone calls and chat will be considered > peer-to-peer (unless incoming calls are disabled). This does not necessarily > refer to how a particular application is implemented. > > > > > Hope this helps. > > > > regards > > > > Richard > > Thanks. > > regards, > suresh > > ===== > > __________________________________________________ > Do You Yahoo!? > Make international calls for as low as $.04/minute with Yahoo! Messenger > http://phonecard.yahoo.com/ > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 31 08:54:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14464 for ; Tue, 31 Jul 2001 08:54:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03905; Tue, 31 Jul 2001 08:53:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03841 for ; Tue, 31 Jul 2001 08:53:10 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14414 for ; Tue, 31 Jul 2001 08:52:09 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A9A4CBD01E4; Tue, 31 Jul 2001 08:50:44 -0400 Message-ID: <005001c119bf$adfd6f80$2300000a@acmepacket.com> From: "Bob Penfield" To: "Pyda Srisuresh" , References: <20010731042222.81809.qmail@web13807.mail.yahoo.com> Subject: Re: [midcom] Framework comments & suggestions Date: Tue, 31 Jul 2001 08:52:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.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 Pyda Srisuresh wrote: > --- Bob Penfield wrote: > > I have several comments on the framework document, mostly minor issues. > > > > Section 2.6 states that "ALGs are not visible to end-hosts". I don't think > > that this is necessarily true. If fact, since OOP agents are out for now, > > the MIDCOM framework requires that the ALG functionality be embedded either > > in a proxy or an end-host (or other entity that is in-path) instead of in > > the middlebox as it is today. Based on this definition, an ALG cannot be a > > MIDCOM agent since it is not "naturally in the message path". I suggest the > > Just because an ALG is in the natural path of an application, that > does not mean that the agent should be visible to end-hosts. > > I dont see how the ALG definition conflicts with the In-Path MIDCOM agent. > OK, I'm a bit confused. The paragraph implies that proxies are visible to end-hosts, yet if the "path" goes from one end through 3 proxies and to the other end, the middle proxy is not necessarily "visible" to the end hosts. Are you implying the same thing for ALGs? I don't see how an ALG can be in the natural path of the application without be known or visible to either an end host or proxy along the way. Today, with the ALG embedded in the middlebox, it can be invisible to the application elements (proxies & end hosts). But in order to put the ALG in an agent external to the middlebox, the application must specifically send at least control traffic to the agent (i.e. the application element co-resident with the agent). If the ALG in the agent is not visible to an application element then some sort of diversion is required to get the packets to the agent which makes it an OOP agent. What am I missing here? > > > > In section 2.8, I suggest the following wording to clarify the difference > > between an in-path and out-of-path agent. > > > > The MIDCOM framework is specifically designed for applications > > that consist of signaling/control sessions and media/data > > sessions. These control and data flows may traverse > > different paths through the network. In order to perform the > > ALG function, MIDCOM agents must access the control messages. > > This document considers only MIDCOM agents co-resident on > > devices that are naturally in the control message path > > of an application. These are also referred to as "In-Path MIDCOM agents". > > This may be an application proxy, gateway, or in the extreme case, > > one of the end-hosts, that is party to the application. > > > > Agents not resident on entities that are natively in the path of > > application flows are referred to as Out-of-Path (OOP) agents. These > > require that control messages be diverted from their natural path to > > the agents and then reinjected into the path. OOP agents will be > > considered out of scope for this document. As such, there will > > be no further discussion on OOP agents in the reminder of this > > document. > > > Bob - this portion of the text went through multiple edits. > I really dont want to change the text unless absolutely necessary. > Why go into the details of diversion function for OOP agents, when > the WG does not want to pursue that discussion. That will simply > raise additional questions - all in an area the WG is queasy about. > So, my druthers is to leave the text as is. Hope you understand. > Thanks. I know this has been a contentious issue, but I believe that confusion over what is in-path vs. out-of-path persists (including my own above). Unless we clearly differentiate these two, I believe this confusion will continue. I guess the most important idea that I think is needed in the definition of the in-path agent is that the control messages and not necessarily the data messages have to traverse the box that included the MIDCOM agent. thanks, (-:bob _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 31 09:42:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15710 for ; Tue, 31 Jul 2001 09:42:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05261; Tue, 31 Jul 2001 09:42:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05230 for ; Tue, 31 Jul 2001 09:42:03 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15690 for ; Tue, 31 Jul 2001 09:41:01 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6VDdFJ00493; Tue, 31 Jul 2001 06:39:44 -0700 (PDT) Received: from cisco.com (sjc-vpn2-175.cisco.com [10.21.112.175]) by airborne.cisco.com (Mirapoint) with SMTP id AID14984; Tue, 31 Jul 2001 06:41:01 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Tue, 31 Jul 2001 09:41:00 -0400 Date: Tue, 31 Jul 2001 09:41:00 -0400 From: Scott Brim To: Pyda Srisuresh Cc: Bob Penfield , midcom@ietf.org Subject: Re: [midcom] Framework comments & suggestions Message-ID: <20010731094100.C1452@SBRIM-W2K> Mail-Followup-To: Scott Brim , Pyda Srisuresh , Bob Penfield , midcom@ietf.org References: <005f01c11903$4e2db860$2300000a@acmepacket.com> <20010731042222.81809.qmail@web13807.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010731042222.81809.qmail@web13807.mail.yahoo.com>; from srisuresh@yahoo.com on Mon, Jul 30, 2001 at 09:22:22PM -0700 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Mon, Jul 30, 2001 at 09:22:22PM -0700, Pyda Srisuresh wrote: > --- Bob Penfield wrote: > > In section 6.0, it says: > > > > The Policy server does not assist a > > middlebox in the implementation of the services it provides or > > with resource authorization on the middlebox > > > > Why not? Why should MIDCOM impose a restriction what a middlebox and its > > policy server can do? What role a policy server plays beyond the > > registration and authorization of agents is beyond the scope of MIDCOM and > > we should not attempt to describe what is does or does not do. This sentence > > should be removed. > > > The sentence is there to state what the policy server cannot be > expected to do. Hope the following rewording will work for you. > > The Policy server is not intended to assist middlebox in the > implementation of the services it provides or with resource > authorization on the middlebox. I think Bob's concern stems from mixing boxes and functions again. The policy server *function* is strictly a policy server. It may be bundled with other functions which support services, and doing so is beyond what we care about. I think the sentence that was already there is clearer. While the new sentence is tolerable, it hints at other unspecified issues -- that's its intention, but doing so reduces clarity. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 31 09:52:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15924 for ; Tue, 31 Jul 2001 09:52:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05401; Tue, 31 Jul 2001 09:48:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05371 for ; Tue, 31 Jul 2001 09:48:50 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15834 for ; Tue, 31 Jul 2001 09:47:48 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6VDkPJ03185 for ; Tue, 31 Jul 2001 06:46:30 -0700 (PDT) Received: from cisco.com (sjc-vpn2-175.cisco.com [10.21.112.175]) by airborne.cisco.com (Mirapoint) with SMTP id AID15020; Tue, 31 Jul 2001 06:48:11 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Tue, 31 Jul 2001 09:48:10 -0400 Date: Tue, 31 Jul 2001 09:48:10 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: Nits (was: RE: [midcom] Comments on Framework 03 draft) Message-ID: <20010731094810.D1452@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <20010731015448.20780.qmail@web13803.mail.yahoo.com> <3B664ED5.ACD0ABF2@obsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B664ED5.ACD0ABF2@obsoft.com>; from sardana@obsoft.com on Mon, Jul 30, 2001 at 11:23:17PM -0700 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Peer-to-peer means intermediaries are not *required*. Communication at certain layers may be peer-to-peer while lower layers are not. Proxy-mediated communication is not peer-to-peer in general, while ALGs may still allow higher layers to experience peer-to-peer relationships. This is a small nit, but it is one of many. If we want this draft to survive last call, could we possibly schedule an editing session in the lobby early in the week? ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 31 10:13:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16975 for ; Tue, 31 Jul 2001 10:13:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06005; Tue, 31 Jul 2001 10:12:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05971 for ; Tue, 31 Jul 2001 10:12:41 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16810 for ; Tue, 31 Jul 2001 10:11:38 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6VEC9g01869 for ; Tue, 31 Jul 2001 07:12:09 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp122.cisco.com [10.21.64.122]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ATH05325; Tue, 31 Jul 2001 07:12:06 -0700 (PDT) Message-Id: <5.1.0.14.0.20010731101140.00a1a0e0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 31 Jul 2001 10:13:24 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Fwd: midcom agenda Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org For some reason our agenda hasn't been announced and isn't showing up on the IETF web site, although I've sent it twice. Here, therefore, is the current version of the agenda. Melinda >Date: Mon, 23 Jul 2001 13:51:47 -0400 >To: agenda@ietf.org >From: Melinda Shore >Subject: midcom agenda > >Middlebox Communication WG (midcom) > >Friday, August 11 at 0900-1130 >================================== > >CHAIR: Melinda Shore > >AGENDA: > >Agenda bashing, scribe >Status >Framework document >Requirements document >Futures > >DOCUMENTS: >http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-03.txt >http://www.ietf.org/internet-drafts/draft-ietf-midcom-requirements-01.txt _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 31 11:13:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20667 for ; Tue, 31 Jul 2001 11:13:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07601; Tue, 31 Jul 2001 11:13:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07573 for ; Tue, 31 Jul 2001 11:12:59 -0400 (EDT) Received: from web14310.mail.yahoo.com (web14310.mail.yahoo.com [216.136.224.60]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20601 for ; Tue, 31 Jul 2001 11:11:58 -0400 (EDT) Message-ID: <20010731151258.91752.qmail@web14310.mail.yahoo.com> Received: from [207.164.4.32] by web14310.mail.yahoo.com; Tue, 31 Jul 2001 11:12:58 EDT Date: Tue, 31 Jul 2001 11:12:58 -0400 (EDT) From: Abdallah Rayhan Subject: Re: [midcom] Framework comments & suggestions To: midcom@ietf.org In-Reply-To: <20010731094100.C1452@SBRIM-W2K> 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 The original sentence is clear and up to the point. It specifies what the middlebox not to expect from the policy server in the context of the MIDCOM framework. The main reason of it is to focus the attention on the agent/middlebox interaction implementing the MIDCOM distributed architecture. If it is necessary to address the policy server/middlebox issues, I would propose the following text, "In the context of the MIDCOM Framework, the policy server does not assist a middlebox in the implementation of the services it provides or with resource authorization on the middlebox." and the policy server outside of the MIDCOM framework is out of scope. regards Abdallah --- Scott Brim wrote: > On Mon, Jul 30, 2001 at 09:22:22PM -0700, Pyda Srisuresh wrote: > > --- Bob Penfield wrote: > > > In section 6.0, it says: > > > > > > The Policy server does not assist > a > > > middlebox in the implementation of the services it provides or > > > with resource authorization on the middlebox > > > > > > Why not? Why should MIDCOM impose a restriction what a middlebox > and its > > > policy server can do? What role a policy server plays beyond the > > > registration and authorization of agents is beyond the scope of > MIDCOM and > > > we should not attempt to describe what is does or does not do. > This sentence > > > should be removed. > > > > > The sentence is there to state what the policy server cannot be > > expected to do. Hope the following rewording will work for you. > > > > The Policy server is not intended to assist middlebox in the > > implementation of the services it provides or with resource > > authorization on the middlebox. > > I think Bob's concern stems from mixing boxes and functions again. > The > policy server *function* is strictly a policy server. It may be > bundled > with other functions which support services, and doing so is beyond > what > we care about. I think the sentence that was already there is > clearer. > While the new sentence is tolerable, it hints at other unspecified > issues -- that's its intention, but doing so reduces clarity. > > ..Scott > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom _______________________________________________________ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 31 11:34:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21695 for ; Tue, 31 Jul 2001 11:34:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08471; Tue, 31 Jul 2001 11:33:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08444 for ; Tue, 31 Jul 2001 11:33:30 -0400 (EDT) Received: from web13801.mail.yahoo.com (web13801.mail.yahoo.com [216.136.175.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21633 for ; Tue, 31 Jul 2001 11:32:29 -0400 (EDT) Message-ID: <20010731153330.3076.qmail@web13801.mail.yahoo.com> Received: from [66.89.112.150] by web13801.mail.yahoo.com; Tue, 31 Jul 2001 08:33:30 PDT Date: Tue, 31 Jul 2001 08:33:30 -0700 (PDT) From: Pyda Srisuresh Subject: Re: Nits (was: RE: [midcom] Comments on Framework 03 draft) To: Scott Brim , midcom@ietf.org In-Reply-To: <20010731094810.D1452@SBRIM-W2K> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --- Scott Brim wrote: > Peer-to-peer means intermediaries are not *required*. Communication at > certain layers may be peer-to-peer while lower layers are not. > Proxy-mediated communication is not peer-to-peer in general, while ALGs > may still allow higher layers to experience peer-to-peer relationships. > > This is a small nit, but it is one of many. If we want this draft to > survive last call, could we possibly schedule an editing session in the > lobby early in the week? > Sounds good. Why dont we schedule a meeting, say Tuesday @8:00 PM in the main lobby. Those of you who can come, please send me a private e-mail. I will send you an edited copy (with all the corrections that came about in the past few days of the last call) by the end of the week and we can go from there. Thanks. Scott - I am assuming, you will be joining, right. DO let me know, if the time I proposed wont work. We can pick a different time. Thanks. > ..Scott > regards, suresh ===== __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 31 11:41:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22089 for ; Tue, 31 Jul 2001 11:41:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08653; Tue, 31 Jul 2001 11:40:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08625 for ; Tue, 31 Jul 2001 11:40:42 -0400 (EDT) Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22013 for ; Tue, 31 Jul 2001 11:39:41 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id 03730816E for ; Tue, 31 Jul 2001 10:40:42 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id KAA16717 for ; Tue, 31 Jul 2001 10:40:41 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Tue, 31 Jul 2001 10:40:41 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Framework comments & suggestions In-Reply-To: <005001c119bf$adfd6f80$2300000a@acmepacket.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Tue, 31 Jul 2001, Bob Penfield wrote: > I know this has been a contentious issue, but I believe that confusion over > what is in-path vs. out-of-path persists (including my own above). Unless we > clearly differentiate these two, I believe this confusion will continue. In the first place, it's out of scope ;) In the second place, the distinction is, as I understand it, this: In-path agents use information from IP packets IP addressed to the agent host. Out-of-path agents use information from IP packets IP addressed to some other host. You could get all pedantic about how you COULD have a "sniffing" widget that behaves like an out-of-path agent but co-resides on the same box as the endpoint, and then you have to get fussy about transport layer addressing and to which application the packets were addressed and so on. I think my definition captures the essence conveniently, though. The point about OOP agents is that someone needs to get the packets TO or at least NEAR (for sniffing) the agent. At one point, it seemed natural to allow MIDCOM to support requests for such. Shoot, it still sounds natural. I don't think it was ever a requirement that an OOP Agent SHALL get its access to data via a middlebox, it could get it by mental telepathy for all I care. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 31 11:41:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22129 for ; Tue, 31 Jul 2001 11:41:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08713; Tue, 31 Jul 2001 11:41:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08682 for ; Tue, 31 Jul 2001 11:41:43 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22069 for ; Tue, 31 Jul 2001 11:40:42 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6VFfN321947; Tue, 31 Jul 2001 08:41:23 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp122.cisco.com [10.21.64.122]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ATI01764; Tue, 31 Jul 2001 08:41:10 -0700 (PDT) Message-Id: <5.1.0.14.0.20010731113851.009fcc60@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 31 Jul 2001 11:42:26 -0400 To: Pyda Srisuresh , midcom@ietf.org From: Melinda Shore Subject: Re: Nits (was: RE: [midcom] Comments on Framework 03 draft) In-Reply-To: <20010731153330.3076.qmail@web13801.mail.yahoo.com> References: <20010731094810.D1452@SBRIM-W2K> 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 08:33 AM 7/31/01 -0700, Pyda Srisuresh wrote: >Sounds good. Why dont we schedule a meeting, say Tuesday @8:00 PM in the >main lobby. Please try to keep some flexibility in your choice of time slot - that falls during the social event, which may be an issue for a number of people. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 31 11:43:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22210 for ; Tue, 31 Jul 2001 11:43:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08770; Tue, 31 Jul 2001 11:42:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08741 for ; Tue, 31 Jul 2001 11:42:10 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22105 for ; Tue, 31 Jul 2001 11:41:08 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6VFfrY25000; Tue, 31 Jul 2001 08:41:53 -0700 (PDT) Received: from cisco.com (sjc-vpn2-175.cisco.com [10.21.112.175]) by airborne.cisco.com (Mirapoint) with SMTP id AIH00435; Tue, 31 Jul 2001 08:41:37 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Tue, 31 Jul 2001 11:41:37 -0400 Date: Tue, 31 Jul 2001 11:41:36 -0400 From: Scott Brim To: Pyda Srisuresh Cc: midcom@ietf.org Subject: Re: Nits (was: RE: [midcom] Comments on Framework 03 draft) Message-ID: <20010731114136.D1076@SBRIM-W2K> Mail-Followup-To: Scott Brim , Pyda Srisuresh , midcom@ietf.org References: <20010731094810.D1452@SBRIM-W2K> <20010731153330.3076.qmail@web13801.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010731153330.3076.qmail@web13801.mail.yahoo.com>; from srisuresh@yahoo.com on Tue, Jul 31, 2001 at 08:33:30AM -0700 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Tue, Jul 31, 2001 at 08:33:30AM -0700, Pyda Srisuresh wrote: > > --- Scott Brim wrote: > > Peer-to-peer means intermediaries are not *required*. Communication at > > certain layers may be peer-to-peer while lower layers are not. > > Proxy-mediated communication is not peer-to-peer in general, while ALGs > > may still allow higher layers to experience peer-to-peer relationships. > > > > This is a small nit, but it is one of many. If we want this draft to > > survive last call, could we possibly schedule an editing session in the > > lobby early in the week? > > > > Sounds good. Why dont we schedule a meeting, say Tuesday @8:00 PM in the > main lobby. Those of you who can come, please send me a private e-mail. > I will send you an edited copy (with all the corrections that came > about in the past few days of the last call) by the end of the week > and we can go from there. Thanks. > > Scott - I am assuming, you will be joining, right. DO let me know, if > the time I proposed wont work. We can pick a different time. Thanks. Sounds good. We can have an alternative social event :-) _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 31 12:02:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23188 for ; Tue, 31 Jul 2001 12:02:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09193; Tue, 31 Jul 2001 11:59:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09163 for ; Tue, 31 Jul 2001 11:59:27 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22919 for ; Tue, 31 Jul 2001 11:58:26 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A54AA2F025E; Tue, 31 Jul 2001 11:56:58 -0400 Message-ID: <002501c119d9$af07b4c0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Pyda Srisuresh" , , "Melinda Shore" References: <20010731094810.D1452@SBRIM-W2K> <5.1.0.14.0.20010731113851.009fcc60@mira-sjc5-4.cisco.com> Subject: Re: Nits (was: RE: [midcom] Comments on Framework 03 draft) Date: Tue, 31 Jul 2001 11:58:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Melinda Shore" To: "Pyda Srisuresh" ; Sent: Tuesday, July 31, 2001 11:42 AM Subject: Re: Nits (was: RE: [midcom] Comments on Framework 03 draft) > At 08:33 AM 7/31/01 -0700, Pyda Srisuresh wrote: > >Sounds good. Why dont we schedule a meeting, say Tuesday @8:00 PM in the > >main lobby. > > Please try to keep some flexibility in your choice of time slot - > that falls during the social event, which may be an issue for a > number of people. I agree. All work and no play makes Johnny a dull boy. Can we find a different time. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 31 12:05:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23346 for ; Tue, 31 Jul 2001 12:05:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10039; Tue, 31 Jul 2001 12:03:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10003 for ; Tue, 31 Jul 2001 12:03:01 -0400 (EDT) Received: from web13806.mail.yahoo.com (web13806.mail.yahoo.com [216.136.175.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23156 for ; Tue, 31 Jul 2001 12:01:59 -0400 (EDT) Message-ID: <20010731160300.78972.qmail@web13806.mail.yahoo.com> Received: from [66.89.112.150] by web13806.mail.yahoo.com; Tue, 31 Jul 2001 09:03:00 PDT Date: Tue, 31 Jul 2001 09:03:00 -0700 (PDT) From: Pyda Srisuresh Subject: Re: Nits (was: RE: [midcom] Comments on Framework 03 draft) To: Bob Penfield , midcom@ietf.org, Melinda Shore In-Reply-To: <002501c119d9$af07b4c0$2300000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I am there the whole week. Most likely, any time in the evening will work for me. Any thoughts on alternate time? Thanks. cheers, suresh --- Bob Penfield wrote: > > > > ----- Original Message ----- > From: "Melinda Shore" > To: "Pyda Srisuresh" ; > Sent: Tuesday, July 31, 2001 11:42 AM > Subject: Re: Nits (was: RE: [midcom] Comments on Framework 03 draft) > > > > At 08:33 AM 7/31/01 -0700, Pyda Srisuresh wrote: > > >Sounds good. Why dont we schedule a meeting, say Tuesday @8:00 PM in the > > >main lobby. > > > > Please try to keep some flexibility in your choice of time slot - > > that falls during the social event, which may be an issue for a > > number of people. > > I agree. All work and no play makes Johnny a dull boy. > > Can we find a different time. > ===== __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 31 12:11:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23622 for ; Tue, 31 Jul 2001 12:11:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10288; Tue, 31 Jul 2001 12:08:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10253 for ; Tue, 31 Jul 2001 12:08:43 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23393 for ; Tue, 31 Jul 2001 12:07:41 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6VG8Dg06538 for ; Tue, 31 Jul 2001 09:08:13 -0700 (PDT) Received: from cisco.com (sjc-vpn2-175.cisco.com [10.21.112.175]) by airborne.cisco.com (Mirapoint) with SMTP id AIH00795; Tue, 31 Jul 2001 09:08:12 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Tue, 31 Jul 2001 12:08:11 -0400 Date: Tue, 31 Jul 2001 12:08:11 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] framework comments Message-ID: <20010731120810.A324@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <3B6099F3.2020402@cisco.com> <20010731033924.3097.qmail@web13803.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010731033924.3097.qmail@web13803.mail.yahoo.com>; from srisuresh@yahoo.com on Mon, Jul 30, 2001 at 08:39:24PM -0700 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Mon, Jul 30, 2001 at 08:39:24PM -0700, Pyda Srisuresh wrote: > > --- Eliot Lear wrote: > > It is necessary for authorization to occur within the midcom protocol. > > The conditions of that authorization may be based on characteristics > > taken from any part of the protocol stack. That is the nature of > > policy. However, the communication that is authorized is a > > TCP/UDP/SCTP/etc. tuple. > > > > The way these decisions are made may require the midcom agent to pass to > > the middlebox opaque application level information that it MAY in turn > > pass onto an appropriate policy server. This information does need to > > be structured and supported by the protocol, and may even be multiple > > blocks that are passed to different policy servers. Consider a policy > > server that handles voice, allowing voice sessions of < 64 kb/s for > > lengths of time <= 4 hours, but a separate policy server that restricts > > communications with my competitors and stock broker ;-) > > > > We discussed this before on ths list. We agreed that the only policy > server this WG will look into is the policy server authorizng the > agents. Any application or user specific policy decisions are considered > out of bounds for this WG. > (Refer last paragraph in section 2.9). That's not what I recall. Obviously policy interactions which don't involve a middlebox aren't our concern. However, I and others were saying that the middlebox may wish to communicate with a policy server for AAA for specific agent transactions. I will attach some excerpts at the end of this. As far as I can tell these were the last comments. They didn't get a response, the conversation was never resolved and the draft remains unchanged. It's on the list of things I decided to let go, but since it's come back, I think it should be resolved. Eliot has a good point. The assumption that there is "a policy server" is not necessary and is restrictive. Easiest fix would be to say "policy services". You can also add a *tentative* statement that the midcom protocol will need to indicate somehow what type of request this is (as in Eliot's example), which could either be in the protocol, or in agent registration, or somewhere. Meanwhile, in the requirements document, we need to decide what exactly is required. In any case, it's a valid point that a single policy server should be required to know everything. Mail excerpts follow. Melinda in response to Suresh: > > I believe, the policy server is a repertoire of information > > pertaining to various agents (that can connect to middlebox). The > > Policy server has no knowledge of middlebox service and as such > > cannot help a middlebox with any of the run-time policy decisions > > pertaining to middlebox resource control. > > All the policy server can do is manage and distribute policy data. > That data could potentially be pretty much anything, and since we > haven't yet talked much about what kind of data would be needed to > support firewall and NAT services I think it's premature to say that > it will never be consulted during a middlebox transaction. Scott in response to Suresh: > > > Second, as discussed on the mailing list, there are two different > > > kinds of information which can be obtained from a policy server. > > > You have the them bundled together. The first is general > > > authorization and limits for an agent. The second is information > > > regarding a particular request from an agent. While a middlebox > > > might obtain an agent "profile" either before or when it first > > > makes contact with that agent, it does not necessarily obtain > > > complete rules for treatment of requests from that agent at that > > > time. The text above requires that (or if it doesn't, then you > > > don't mention request-specific rules anywhere :-)). I would add > > > another sentence, something along the lines of "Policy regarding > > > treatment of specific agent requests may be obtained when the > > > agent is first authorized or at any time thereafter." > > > > > What sort of agent requests would require the middlebox to consult > > the Policy Server at run time? DO you have a specific example? > > > > We had a discussion on this thread. Somewhat inconclusive. SO, I > > didnt add any text that is suggestive or not-suggestive of the use > > of Policy Server at run-time by the middlebox. > > As I said, many conversations are inconclusive until we get this close > to last call. Now's the time we work things out. > > OK, here's an example: I have a middlebox which handles communications > for potentially millions of clients, although only a small number > (hundreds?) will be active at any one time. Each customer is > potentially different enough in enough ways that it would take > significant effort to create aggregate rules for them. I don't want to > store rules for all the millions of them in the middlebox since that > would cost me more in hardware and in any case the initialization time > would ruin my availability numbers. So I feed the middlebox some > general policy to start with -- such as which agents are authorized > for what, in general terms -- and when it gets a specific connection > request, it queries the policy server which generates the > customer-specific policy on the fly (from info in a database) and > returns it. See? Agent-related policy comes first, then > customer-related policy later. They don't have to, but I want to > allow this possibility for the service providers. > > My concern here is that your language explicitly mentions the agent > profile and stops as if that's all there is. Perhaps you could say > something like ... "gain access to middlebox resources. A middlebox > and a policy server may communicate further if the policy server's > policy changes or if a middlebox needs further information." _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 31 12:26:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24735 for ; Tue, 31 Jul 2001 12:26:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10739; Tue, 31 Jul 2001 12:24:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10706 for ; Tue, 31 Jul 2001 12:24:06 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24460 for ; Tue, 31 Jul 2001 12:23:04 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6VGNeg18798 for ; Tue, 31 Jul 2001 09:23:40 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp122.cisco.com [10.21.64.122]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ATK01023; Tue, 31 Jul 2001 09:23:34 -0700 (PDT) Message-Id: <5.1.0.14.0.20010731122401.00a1e980@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 31 Jul 2001 12:24:49 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Incorrect URL Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I sent out the incorrect URL for the requirements draft. It should be: http://www.ietf.org/internet-drafts/draft-ietf-midcom-requirements-02.txt Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 31 12:35:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25356 for ; Tue, 31 Jul 2001 12:35:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11278; Tue, 31 Jul 2001 12:32:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11251 for ; Tue, 31 Jul 2001 12:32:57 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25033 for ; Tue, 31 Jul 2001 12:31:54 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AD26E8A022A; Tue, 31 Jul 2001 12:30:30 -0400 Message-ID: <004801c119de$5ca90760$2300000a@acmepacket.com> From: "Bob Penfield" To: "Abdallah Rayhan" , References: <20010731151258.91752.qmail@web14310.mail.yahoo.com> Subject: Re: [midcom] Framework comments & suggestions Date: Tue, 31 Jul 2001 12:32:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Abdallah Rayhan" To: Sent: Tuesday, July 31, 2001 11:12 AM Subject: Re: [midcom] Framework comments & suggestions > The original sentence is clear and up to the point. It > specifies what the middlebox not to expect from the policy > server in the context of the MIDCOM framework. The main > reason of it is to focus the attention on the agent/middlebox > interaction implementing the MIDCOM distributed architecture. > If it is necessary to address the policy server/middlebox > issues, I would propose the following text, > > "In the context of the MIDCOM Framework, the policy > server does not assist a middlebox in the implementation > of the services it provides or with resource authorization > on the middlebox." > I like this wording the best. _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 31 18:58:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00509 for ; Tue, 31 Jul 2001 18:58:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21981; Tue, 31 Jul 2001 18:51:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21950 for ; Tue, 31 Jul 2001 18:51:34 -0400 (EDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29971 for ; Tue, 31 Jul 2001 18:50:35 -0400 (EDT) Received: from cisco.com (elear-dsl4.cisco.com [10.19.144.53]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA21774; Tue, 31 Jul 2001 15:41:25 -0700 (PDT) Message-ID: <3B673414.21D5E1CB@cisco.com> Date: Tue, 31 Jul 2001 15:41:24 -0700 From: Eliot Lear Reply-To: lear@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pyda Srisuresh CC: midcom@ietf.org Subject: Re: [midcom] framework comments References: <20010731033924.3097.qmail@web13803.mail.yahoo.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 Hi, Comments in line. Pyda Srisuresh wrote: > > "packet filtering" is but one type of firewall. We should borrow a > > better definition from elsewhere. > > > > Eliot - There may be many variations to the theme, all eventually > boiling down to packet permitting/filtering. The purpose was merely > to expose this aspect of the firewall from middlebox function > perspective. > > As I recall, there were multiple semantics associated with the term, > at the time the discussion got started on the list. Some implying > NAT function and IPsec Gateway function and so forth - all included > in the same term. > > I believe, the current definition will suffie for the purposes of > MIDCOM FW. There are two reasons I would like to find a better definition. One is simply on the faith that someone else has done the work. The second is that I have a specific example in mind: application firewalls are NOT packet filtering firewalls. Perhaps just dropping the words "packet filtering" might do fine. > > > Figure 3 - you skipped or removed step "5". > > > > OK. > > > I'm also interested in changing some wording to the protocol > > requirements, and a more general statement about protocol layering. Bob > > Braden's recent post to the IETF I think is most concerning. > > > > Not sure what you are talkig about. I didnt see the e-mail from Bob Braden. > Were you going to suggest somethign specific to framework draft? There was a discussion on the IETF list about layering, which I what I'm referring to. > We discussed this before on ths list. We agreed that the only policy > server this WG will look into is the policy server authorizng the > agents. Any application or user specific policy decisions are considered > out of bounds for this WG. > (Refer last paragraph in section 2.9). I largely agree with the caveat that we need a method to pass opaque information to the policy server in order to make its decision. I seem to recall in earlier discussion that I wouldn't want that becoming a huge chatty conversation, but more of an EHLO-like exchange some of which could be cached. -- Eliot Lear lear@cisco.com _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 31 22:49:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19419 for ; Tue, 31 Jul 2001 22:49:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA27086; Tue, 31 Jul 2001 22:42:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA27059 for ; Tue, 31 Jul 2001 22:42:57 -0400 (EDT) Received: from web13807.mail.yahoo.com (web13807.mail.yahoo.com [216.136.175.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18341 for ; Tue, 31 Jul 2001 22:41:54 -0400 (EDT) Message-ID: <20010801024255.76932.qmail@web13807.mail.yahoo.com> Received: from [66.89.112.150] by web13807.mail.yahoo.com; Tue, 31 Jul 2001 19:42:55 PDT Date: Tue, 31 Jul 2001 19:42:55 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Framework comments & suggestions To: Bob Penfield , Abdallah Rayhan , midcom@ietf.org In-Reply-To: <004801c119de$5ca90760$2300000a@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --- Bob Penfield wrote: > > > ----- Original Message ----- > From: "Abdallah Rayhan" > To: > Sent: Tuesday, July 31, 2001 11:12 AM > Subject: Re: [midcom] Framework comments & suggestions > > > > The original sentence is clear and up to the point. It > > specifies what the middlebox not to expect from the policy > > server in the context of the MIDCOM framework. The main > > reason of it is to focus the attention on the agent/middlebox > > interaction implementing the MIDCOM distributed architecture. > > If it is necessary to address the policy server/middlebox > > issues, I would propose the following text, > > > > "In the context of the MIDCOM Framework, the policy > > server does not assist a middlebox in the implementation > > of the services it provides or with resource authorization > > on the middlebox." > > > > I like this wording the best. > > I like it as well. Let's go with it. Thanks. regards, suresh > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www.ietf.org/mailman/listinfo/midcom __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Jul 31 23:55:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA23921 for ; Tue, 31 Jul 2001 23:55:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28102; Tue, 31 Jul 2001 23:55:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28077 for ; Tue, 31 Jul 2001 23:55:11 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA23852 for ; Tue, 31 Jul 2001 23:54:08 -0400 (EDT) Received: from MDUFFY ([10.1.1.15]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PDZ56LQ2; Tue, 31 Jul 2001 23:54:39 -0400 Message-Id: <3.0.5.32.20010731235321.007db550@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 31 Jul 2001 23:53:21 -0400 To: Andrew Molitor , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Framework comments & suggestions In-Reply-To: References: <005001c119bf$adfd6f80$2300000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 10:40 AM 7/31/01 -0500, Andrew Molitor wrote: ... > In the second place, the distinction is, as I understand it, >this: > > In-path agents use information from IP packets IP > addressed to the agent host. > Out-of-path agents use information from IP packets > IP addressed to some other host. This was not my understanding. I am surprised in fact not to see any responses to the above post (so far). Does the silence mean everyone agrees with the above statement? I guess we can at least conclude that the definition of in-path agent "...devices that are naturally within the message path of the application" is too vague! Andrew's definition strikes me as unnecessarily restrictive of what can be an in-path agent (and therefore an in-scope agent :-) Consider the pre-midcom case where a middlebox, say a firewall, embeds application intelligence in order to do its job. None of the application packets would be IP-addressed to the firewall. Now consider the midcom-ized evolution of that picture. We can shift the application intelligence out of that firewall and into a midcom agent that is within the path traversed by the packets. Why should it be a precondition to doing so that the application now address its packets to the agent? All this serves to do is to prevent (as a side effect) the use of midcom for any application that is not using some sort of proxy. -Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www.ietf.org/mailman/listinfo/midcom