From midcom-admin@ietf.org Sat Sep 1 01:15:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26505 for ; Sat, 1 Sep 2001 01:15: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 BAA08957; Sat, 1 Sep 2001 01:07: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 BAA08853 for ; Sat, 1 Sep 2001 01:07:15 -0400 (EDT) Received: from market0 ([208.158.105.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25215 for ; Sat, 1 Sep 2001 01:05:53 -0400 (EDT) From: adv1@market.gogocity.com Received: from mail pickup service by market0 with Microsoft SMTPSVC; Fri, 31 Aug 2001 22:03:45 -0700 To: Date: Fri, 31 Aug 2001 22:03:44 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_20F41C_01C13268.CD6AA330" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 01 Sep 2001 05:03:45.0380 (UTC) FILETIME=[7A2B4A40:01C132A3] Subject: [midcom] Retire Beanie Babies Save Up to 50% Sender: 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_20F41C_01C13268.CD6AA330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 Big Saving from GoGoCity. If you'd rather not receive any future promotional E-mails from GoGoCity.com,=20 please click --> Un-Subscribe My E-mai l =20 International Order Welcome FREE SHIPPING NOT APPLY=20 ty=AE Beanie Babies (Retired)=20 Britannia Original Buddy Britannia Original Buddy click for large image Retail Price: $199.00 Out Price: $99.99(save 50%) More Details... =20 ty=AE Beanie Babies Special Sale Retails for $29.95~299.99 ( Save Up to 50% ) Now Only.....$99.99=20 This is an opportunity you don't want to miss and a great one to add to your collection.=20 Limited Quantities, Hurry UP......!!!!! =20 1. BRITANNIA ORIGINAL BUDDY 2. VALENTINO TY BEANIE BUDDY =20 Britannia Original Buddy large image =20 Retail Price: $199.00 Out Price: $99.99 (save 50%) More Details... =20 Buy it NOW !! =20 VALENTINO TY BEANIE BUDDY large image =20 Retail Price: $29.95 Out Price: $14.95 (save 50%) More Details... =20 Buy it NOW !! =20 =09 3. BRITANNIA THE BRITISH BEAR 4. NIPPONIA THE JAPAN BEAR TY BEANIE BEANIE =20 BRITANNIA THE BRITISH BEAR large image =20 Retail Price: $125.99 Out Price: $79.95 (save 37%) More Details... =20 Buy it NOW !! =20 NIPPONIA THE JAPAN BEAR TY BEANIE BEANIE large image =20 Retail Price: $111.95 Out Price: $55.95 (save 50%) More Details... =20 Buy it NOW !! =20 =09 5. CHINOOK THE CANADA BEAR 6. RADAR TY BEANIE BEANIE =20 CHINOOK THE CANADA BEAR large image =20 Retail Price: $69.65 Out Price: $49.95 (save 28%) More Details... =20 Buy it NOW !! =20 RADAR TY BEANIE BEANIE large image =20 Retail Price: $179.95 Out Price: $89.95 (save 50%) More Details... =20 Buy it NOW !! =20 =09 7. CORAL TY BEANIE BABY 8. STING THE STINGRAY TY BEANIE BABY =20 CORAL TY BEANIE BABY large image =20 Retail Price: $179.95 Out Price: $99.95 (save 44%) More Details... =20 Buy it NOW !! =20 STING THE STINGRAY TY BEANIE BABY large image =20 Retail Price: $179.95 Out Price: $129.95 (save 28%) More Details... =20 Buy it NOW !! =20 =09 9. GARCIA THE BEAR TY BEANIE BEANIE 10. TABASCO THE BULL TY BEANIE BEANIE =20 GARCIA THE BEAR TY BEANIE BEANIE large image =20 Retail Price: $299.99 Out Price: $199.95 (save 33%) More Details... =20 Buy it NOW !! =20 TABASCO THE BULL TY BEANIE BEANIE large image =20 Retail Price: $179.95 Out Price: $89.95 (save 50%) More Details... =20 Buy it NOW !! =20 =09 More Hot Item.....Click Here =20 ------=_NextPart_000_20F41C_01C13268.CD6AA330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
=20


Big Saving = from GoGoCity.=20 If you'd rather not receive any future promotional E-mails from = GoGoCity.com,=20
please click --> Un-Subscribe=20 My E-mail
International=20 Order Welcome=20 FREE SHIPPING NOT APPLY

=20
=20
ty®=20 Beanie Babies (Retired) =
=20
=20

Britannia=20 Original Buddy
3D"Britannia
click = for large image
Retail Price:=20 $199.00
Out Price: $99.99(save = 50%)
More=20 Details...

=20

ty®=20 Beanie Babies Special = Sale
Retails for $29.95~299.99=20 (=20 Save Up to 50% )

=20 Now Only.....$99.99=20

This=20 is an opportunity you don't want to miss
and a great one to add to your collection.
= =
Limited=20 Quantities= ,=20 Hurry = UP......!!!!!<= /font><= /b>
=20 =20 =20 =20 =20 =20 =20 =20 =20 =20
1.=20 BRITANNIA = ORIGINAL=20 BUDDY 2.=20 VALENTINO TY BEANIE BUDDY
=20 Retail=20 Price: $199.00
Out Price: $99.99 (save = 50%)
More=20 Details...
Buy it = NOW !!
 =20 Retail=20 Price: $29.95
Out Price: $14.95 (save = 50%)
More=20 Details...
Buy it = NOW !!
3.=20 BRITANNIA THE BRITISH BEAR 4.=20 NIPPONIA THE JAPAN BEAR TY BEANIE BEANIE
=20 Retail=20 Price: $125.99
Out Price: $79.95 (save = 37%)
More=20 Details...
Buy it = NOW !!
 =20 Retail=20 Price: $111.95
Out Price: $55.95 (save = 50%)
More=20 Details...
Buy it = NOW !!
5.=20 CHINOOK THE CANADA BEAR 6.=20 RADAR TY BEANIE BEANIE
=20 Retail=20 Price: $69.65
Out Price: $49.95 (save = 28%)
More=20 Details...
Buy it = NOW !!
 =20 Retail=20 Price: $179.95
Out Price: $89.95 (save = 50%)
More=20 Details...
Buy it = NOW !!
7.=20 CORAL TY BEANIE BABY 8.=20 STING THE STINGRAY TY BEANIE BABY
=20 Retail=20 Price: $179.95
Out Price: $99.95 (save = 44%)
More=20 Details...
Buy it = NOW !!
 =20 Retail=20 Price: $179.95
Out Price: $129.95 (save = 28%)
More=20 Details...
Buy it = NOW !!
9.=20 GARCIA THE BEAR TY BEANIE BEANIE 10.=20 TABASCO THE BULL TY BEANIE BEANIE
=20 Retail=20 Price: $299.99
Out Price: $199.95 (save = 33%)
More=20 Details...
Buy it = NOW !!
 =20 Retail=20 Price: $179.95
Out Price: $89.95 (save = 50%)
More=20 Details...
Buy it = NOW !!

More=20 Hot Item.....Click Here
------=_NextPart_000_20F41C_01C13268.CD6AA330-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 3 10:50:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10946 for ; Mon, 3 Sep 2001 10:50: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 KAA21838; Mon, 3 Sep 2001 10:47: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 KAA21808 for ; Mon, 3 Sep 2001 10:47: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 ESMTP id KAA10840 for ; Mon, 3 Sep 2001 10:45:45 -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 f83Eksv16713; Mon, 3 Sep 2001 07:46:56 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp77.cisco.com [10.21.64.77]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABS06963; Mon, 3 Sep 2001 07:46:31 -0700 (PDT) Message-Id: <5.1.0.14.0.20010903104750.00a738d0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 03 Sep 2001 10:48:14 -0400 To: Scott Brim , midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] R80 In-Reply-To: <20010903104216.A1596@SBRIM-W2K> References: <5.1.0.14.0.20010831114327.00a65b90@mira-sjc5-4.cisco.com> <5.1.0.14.0.20010831114327.00a65b90@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 10:42 AM 9/3/01 -0400, Scott Brim wrote: >I forgot ... does R79 ("If a particular ruleset is created multiple >times, it must be deleted the same number of times.") get deleted as >well? Yes. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 3 10:58:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11039 for ; Mon, 3 Sep 2001 10:58: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 KAA21769; Mon, 3 Sep 2001 10:42: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 KAA21744 for ; Mon, 3 Sep 2001 10:42:38 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10744 for ; Mon, 3 Sep 2001 10:41:12 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f83EgHp09423 for ; Mon, 3 Sep 2001 07:42:17 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-113.cisco.com [10.21.96.113]) by airborne.cisco.com (Mirapoint) with SMTP id AAQ21909; Mon, 3 Sep 2001 07:42:06 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 3 Sep 2001 10:42:17 -0400 Date: Mon, 3 Sep 2001 10:42:16 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] R80 Message-ID: <20010903104216.A1596@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <5.1.0.14.0.20010831114327.00a65b90@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20010831114327.00a65b90@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Fri, Aug 31, 2001 at 11:45:50AM -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 Fri, Aug 31, 2001 11:45:50AM -0400, Melinda Shore allegedly wrote: > The text in R80 has been replaced with the following, which has > the agreement of the working group: > > "It must be possible to deterministically predict the > behavior of the firewall in the presence of overlapping rules." > > This may end up being revisited when the next version of the > requirements document comes out, per Keith's comments about > specificity. I forgot ... does R79 ("If a particular ruleset is created multiple times, it must be deleted the same number of times.") get deleted as well? ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 3 11:17: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 ESMTP id LAA11310 for ; Mon, 3 Sep 2001 11:17: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 LAA22420; Mon, 3 Sep 2001 11:15: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 LAA22390 for ; Mon, 3 Sep 2001 11:15:33 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11263 for ; Mon, 3 Sep 2001 11:14:07 -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 f83FF2821615 for ; Mon, 3 Sep 2001 08:15:02 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-113.cisco.com [10.21.96.113]) by airborne.cisco.com (Mirapoint) with SMTP id AAQ22000; Mon, 3 Sep 2001 08:14:59 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 3 Sep 2001 11:15:10 -0400 Date: Mon, 3 Sep 2001 11:15:10 -0400 From: Scott Brim To: midcom@ietf.org Message-ID: <20010903111510.C1596@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [midcom] new requirements bullets available Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org http://www.employees.org/~swb/midcom.html has the new requirements bullets (010904). We now have 15 accepted, 45 rejected (pretty good) but 29 left to deal with. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 4 04:44:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06029 for ; Tue, 4 Sep 2001 04:44: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 EAA16760; Tue, 4 Sep 2001 04:39: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 EAA16730 for ; Tue, 4 Sep 2001 04:39:27 -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 ESMTP id EAA05983 for ; Tue, 4 Sep 2001 04:38:01 -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 f848ctg06219 for ; Tue, 4 Sep 2001 09:38:55 +0100 (BST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Tue, 4 Sep 2001 09:38:21 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Sep 2001 09:38:19 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C30445232@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "Midcom IETF (E-mail)" Date: Tue, 4 Sep 2001 09:38:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1351C.F08CA4B0" Subject: [midcom] unused states clean-up Sender: 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_01C1351C.F08CA4B0 Content-Type: text/plain; charset="iso-8859-1" Hi, A while ago when we discussed and argued on how to clean-up no longer used states on a MB, it was agreed that the requirement is to have a mechanism to cleanup these states. Each protocol may have it's own ways to clean them up, ruleset or bundle related timers could be a solution but there are other solutions as well. To summarize I think we need to replace R6 and R81, by the real requirement which is: The protocol should have a state clean-up mechanism for no longer used states Any comments? Cedric ------_=_NextPart_001_01C1351C.F08CA4B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unused states clean-up

Hi,
A while ago when we discussed and = argued on how to clean-up no longer used states on a MB,
it was agreed that the requirement is = to have a mechanism to cleanup these states.
Each protocol may have it's own ways = to clean them up, ruleset or bundle related  timers could be a = solution
but there are other solutions as = well.
To summarize I think we need to = replace R6 and R81, by the real requirement which is:
The protocol should have a state = clean-up mechanism for no longer used states

Any comments?
Cedric

------_=_NextPart_001_01C1351C.F08CA4B0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 4 06:50:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07409 for ; Tue, 4 Sep 2001 06:50: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 GAA19751; Tue, 4 Sep 2001 06:49: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 GAA19725 for ; Tue, 4 Sep 2001 06:49:24 -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 GAA07195; Tue, 4 Sep 2001 06:47:58 -0400 (EDT) Message-Id: <200109041047.GAA07195@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 04 Sep 2001 06:47:58 -0400 Subject: [midcom] I-D ACTION:draft-aoun-midcom-agent-information-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 : Required Information in Midcom Agents Author(s) : C. Aoun, S. Sen Filename : draft-aoun-midcom-agent-information-00.txt Pages : 8 Date : 31-Aug-01 This draft is part of a gladiator contest within the MIDCOM WG to determine what network topology information is needed at the Midcom agent. By taking out application awareness from Middle Boxes in the networks, and keeping this application knowledge in the application devices (the Midcom Agents); sufficient information needs to be put in the Midcom Agent to allow them to fulfill their responsibility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-aoun-midcom-agent-information-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-aoun-midcom-agent-information-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-aoun-midcom-agent-information-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: <20010831125929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-aoun-midcom-agent-information-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-aoun-midcom-agent-information-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010831125929.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 4 10:17:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17081 for ; Tue, 4 Sep 2001 10:17: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 KAA25254; Tue, 4 Sep 2001 10:11: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 KAA25225 for ; Tue, 4 Sep 2001 10:11:42 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16867 for ; Tue, 4 Sep 2001 10:10:16 -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 f84EBF829635; Tue, 4 Sep 2001 07:11:15 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-280.cisco.com [10.21.65.24]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABU00629; Tue, 4 Sep 2001 07:11:09 -0700 (PDT) Message-Id: <5.1.0.14.0.20010904101147.00a57340@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 10:12:52 -0400 To: "Cedric Aoun" , "Midcom IETF (E-mail)" From: Melinda Shore Subject: Re: [midcom] unused states clean-up In-Reply-To: <9154CB41F208D5118DD200508BE39C30445232@zjguc006.europe.nor tel.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 09:38 AM 9/4/01 +0100, Cedric Aoun wrote: >A while ago when we discussed and argued on how to clean-up no longer used states on a MB, >it was agreed that the requirement is to have a mechanism to cleanup these states. >Each protocol may have it's own ways to clean them up, ruleset or bundle related timers could be a solution >but there are other solutions as well. >To summarize I think we need to replace R6 and R81, by the real requirement which is: >The protocol should have a state clean-up mechanism for no longer used states Is R23 insufficient? It says: "R23: The Midcom Protocol MUST enable the Middlebox and any associated Midcom Agents to establish known and stable state. This must include the case of power failure, or other failure, where the protocol must ensure that any resources used by a failed element can be released." Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 4 10:35:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17813 for ; Tue, 4 Sep 2001 10:35: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 KAA25856; Tue, 4 Sep 2001 10:34: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 KAA25825 for ; Tue, 4 Sep 2001 10:34: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 ESMTP id KAA17735 for ; Tue, 4 Sep 2001 10:33:00 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f84EVxn04708 for ; Tue, 4 Sep 2001 07:31:59 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-280.cisco.com [10.21.65.24]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABU01074; Tue, 4 Sep 2001 07:33:52 -0700 (PDT) Message-Id: <5.1.0.14.0.20010904102115.00a570a0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 10:35:34 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Items currently under consideration - status Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org R23: Accepted (my goof) R45: Delete R39, 63: keep R79, 80: Already resolved. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 4 11:01:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18447 for ; Tue, 4 Sep 2001 11:01: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 KAA26330; Tue, 4 Sep 2001 10:58: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 KAA26302 for ; Tue, 4 Sep 2001 10:58:02 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18300 for ; Tue, 4 Sep 2001 10:56:34 -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 f84EvT800743 for ; Tue, 4 Sep 2001 07:57:29 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-113.cisco.com [10.21.96.113]) by airborne.cisco.com (Mirapoint) with SMTP id AAR03361; Tue, 4 Sep 2001 07:57:27 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Tue, 4 Sep 2001 10:57:32 -0400 Date: Tue, 4 Sep 2001 10:57:32 -0400 From: Scott Brim To: "Midcom IETF (E-mail)" Subject: Re: [midcom] unused states clean-up Message-ID: <20010904105732.E1660@SBRIM-W2K> Mail-Followup-To: Scott Brim , "Midcom IETF (E-mail)" References: <9154CB41F208D5118DD200508BE39C30445232@zjguc006.europe.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9154CB41F208D5118DD200508BE39C30445232@zjguc006.europe.nortel.com>; from CEDRIC.AOUN@nortelnetworks.com on Tue, Sep 04, 2001 at 09:38:15AM +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 On Tue, Sep 04, 2001 09:38:15AM +0100, Cedric Aoun allegedly wrote: > Hi, > A while ago when we discussed and argued on how to clean-up no longer used > states on a MB, > it was agreed that the requirement is to have a mechanism to cleanup these > states. > Each protocol may have it's own ways to clean them up, ruleset or bundle > related timers could be a solution > but there are other solutions as well. > To summarize I think we need to replace R6 and R81, by the real requirement > which is: > The protocol should have a state clean-up mechanism for no longer used > states I don't think we ever resolved this in the main group (although we talked about it at the Monday night FOB). My opinion is No -- this is too specific. You want to be sure that state is synchronized deterministically, but that doesn't mean you need a mechanism in the protocol. You may use timers, etc. I think R23 is as far as we want to go in this Working Group. The next WG can get more specific. I think we agree on the requirement, just not the solution, which we should put off. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 4 11:09:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18604 for ; Tue, 4 Sep 2001 11:09: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 LAA26708; Tue, 4 Sep 2001 11:08: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 LAA26679 for ; Tue, 4 Sep 2001 11:08:21 -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 ESMTP id LAA18579 for ; Tue, 4 Sep 2001 11:06:55 -0400 (EDT) Received: from NRPC15 (nrpc-15 [10.10.111.222]) by nrmail01.netrake.net (8.11.1/8.11.1) with SMTP id f84F3Qc14385; Tue, 4 Sep 2001 10:03:26 -0500 Reply-To: From: "Ram Dantu" To: "'Melinda Shore'" , "'Cedric Aoun'" , "'Midcom IETF \(E-mail\)'" Subject: RE: [midcom] unused states clean-up Date: Tue, 4 Sep 2001 10:03:24 -0500 Message-ID: <7E06D3212981524CA10D2A114937C414073C01@NREXCH.netrake.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C13528.D6E943E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5.1.0.14.0.20010904101147.00a57340@mira-sjc5-4.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: 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_0000_01C13528.D6E943E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Does R23 mean the following: MIDCOM protocol to facilitate the exchange of each others stable state (Middlebox and Agent) This helps in cleaning states in either side during failure. Regards Ram Dantu -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Melinda Shore Sent: Tuesday, September 04, 2001 9:13 AM To: Cedric Aoun; Midcom IETF (E-mail) Subject: Re: [midcom] unused states clean-up At 09:38 AM 9/4/01 +0100, Cedric Aoun wrote: >A while ago when we discussed and argued on how to clean-up no longer used states on a MB, >it was agreed that the requirement is to have a mechanism to cleanup these states. >Each protocol may have it's own ways to clean them up, ruleset or bundle related timers could be a solution >but there are other solutions as well. >To summarize I think we need to replace R6 and R81, by the real requirement which is: >The protocol should have a state clean-up mechanism for no longer used states Is R23 insufficient? It says: "R23: The Midcom Protocol MUST enable the Middlebox and any associated Midcom Agents to establish known and stable state. This must include the case of power failure, or other failure, where the protocol must ensure that any resources used by a failed element can be released." Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom ------=_NextPart_000_0000_01C13528.D6E943E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [midcom] unused states clean-up

Does R23 mean the following:
      MIDCOM protocol to = facilitate the exchange of
      each others stable = state (Middlebox and Agent) 

This helps in cleaning states in either side during = failure.

Regards
Ram Dantu

-----Original Message-----
From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On= Behalf Of
Melinda Shore
Sent: Tuesday, September 04, 2001 9:13 AM
To: Cedric Aoun; Midcom IETF (E-mail)
Subject: Re: [midcom] unused states clean-up


At 09:38 AM 9/4/01 +0100, Cedric Aoun wrote:
>A while ago when we discussed and argued on how = to clean-up no longer used states on a MB,
>it was agreed that the requirement is to have a = mechanism to cleanup these states.
>Each protocol may have it's own ways to clean = them up, ruleset or bundle related  timers could be a solution =
>but there are other solutions as well.
>To summarize I think we need to replace R6 and = R81, by the real requirement which is:
>The protocol should have a state clean-up = mechanism for no longer used states

Is R23 insufficient?  It says:

"R23: The Midcom Protocol MUST enable the = Middlebox and any associated
        Midcom = Agents to establish known and stable state.  This must
        include = the case of power failure, or other failure, where the
        protocol = must ensure that any resources used by a failed element
        can be = released."

Melinda


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

------=_NextPart_000_0000_01C13528.D6E943E0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 4 11:12:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18734 for ; Tue, 4 Sep 2001 11:12: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 LAA26799; Tue, 4 Sep 2001 11:11: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 LAA26770 for ; Tue, 4 Sep 2001 11:11: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 ESMTP id LAA18607 for ; Tue, 4 Sep 2001 11:09: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 f84FAd810101 for ; Tue, 4 Sep 2001 08:10:39 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-113.cisco.com [10.21.96.113]) by airborne.cisco.com (Mirapoint) with SMTP id AAR03635; Tue, 4 Sep 2001 08:10:33 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Tue, 4 Sep 2001 11:10:39 -0400 Date: Tue, 4 Sep 2001 11:10:38 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Items currently under consideration - status Message-ID: <20010904111038.F1660@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <5.1.0.14.0.20010904102115.00a570a0@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20010904102115.00a570a0@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Tue, Sep 04, 2001 at 10:35:34AM -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 Tue, Sep 04, 2001 10:35:34AM -0400, Melinda Shore allegedly wrote: > R23: Accepted (my goof) > R45: Delete > R39, 63: keep > R79, 80: Already resolved. OK with me _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 4 13:43:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAB22562 for ; Tue, 4 Sep 2001 13:43: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 NAA01629; Tue, 4 Sep 2001 13:42: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 NAA01600 for ; Tue, 4 Sep 2001 13:42:16 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22478 for ; Tue, 4 Sep 2001 13:40:50 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f84Hg1v11493 for ; Tue, 4 Sep 2001 10:42:01 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-280.cisco.com [10.21.65.24]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABX01225; Tue, 4 Sep 2001 10:41:39 -0700 (PDT) Message-Id: <5.1.0.14.0.20010904133856.00a59b40@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 13:43:15 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Contest of champions Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org So far it looks like there are three submissions for the topology discussion. Please take a look at these as soon as possible, but do be aware that the transport area directors will be evaluating them, too. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 4 14:05:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23094 for ; Tue, 4 Sep 2001 14:05: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 OAA02408; Tue, 4 Sep 2001 14:03: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 OAA02380 for ; Tue, 4 Sep 2001 14:03:08 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23013 for ; Tue, 4 Sep 2001 14:01:41 -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 f84I0dP11583; Tue, 4 Sep 2001 11:00:39 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-280.cisco.com [10.21.65.24]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABX02295; Tue, 4 Sep 2001 11:02:18 -0700 (PDT) Message-Id: <5.1.0.14.0.20010904140112.00a5f180@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 14:03:51 -0400 To: Scott Brim , "Midcom IETF (E-mail)" From: Melinda Shore Subject: Re: [midcom] unused states clean-up In-Reply-To: <20010904105732.E1660@SBRIM-W2K> References: <9154CB41F208D5118DD200508BE39C30445232@zjguc006.europe.nortel.com> <9154CB41F208D5118DD200508BE39C30445232@zjguc006.europe.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 At 10:57 AM 9/4/01 -0400, Scott Brim wrote: >I don't think we ever resolved this in the main group We didn't. >I think >we agree on the requirement, just not the solution, which we should put >off. Is this a proposal to let R6 and R81 stand as is? My one caveat would be that R6 does put a requirement on the behavior of the middlebox. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 4 14:21:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23606 for ; Tue, 4 Sep 2001 14:21: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 OAA02882; Tue, 4 Sep 2001 14:19: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 OAA02852 for ; Tue, 4 Sep 2001 14:19:46 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23520 for ; Tue, 4 Sep 2001 14:18:20 -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 f84IJWv14364 for ; Tue, 4 Sep 2001 11:19:33 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-113.cisco.com [10.21.96.113]) by airborne.cisco.com (Mirapoint) with SMTP id AAR07359; Tue, 4 Sep 2001 11:18:59 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Tue, 4 Sep 2001 14:18:39 -0400 Date: Tue, 4 Sep 2001 14:18:39 -0400 From: Scott Brim To: "Midcom IETF (E-mail)" Subject: Re: [midcom] unused states clean-up Message-ID: <20010904141838.C1816@SBRIM-W2K> Mail-Followup-To: Scott Brim , "Midcom IETF (E-mail)" References: <9154CB41F208D5118DD200508BE39C30445232@zjguc006.europe.nortel.com> <9154CB41F208D5118DD200508BE39C30445232@zjguc006.europe.nortel.com> <20010904105732.E1660@SBRIM-W2K> <5.1.0.14.0.20010904140112.00a5f180@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20010904140112.00a5f180@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Tue, Sep 04, 2001 at 02:03:51PM -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 Tue, Sep 04, 2001 02:03:51PM -0400, Melinda Shore allegedly wrote: > At 10:57 AM 9/4/01 -0400, Scott Brim wrote: > >I don't think we ever resolved this in the main group > > We didn't. > > >I think > >we agree on the requirement, just not the solution, which we should put > >off. > > Is this a proposal to let R6 and R81 stand as is? My one caveat would > be that R6 does put a requirement on the behavior of the middlebox. No, I think they should be deleted in favor of the real, fundamental requirement, R23. Questions about specifics such as timers should be put off until the next incarnation of the WG. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 5 06:50: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 ESMTP id GAA23220 for ; Wed, 5 Sep 2001 06:50: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 GAA03414; Wed, 5 Sep 2001 06:47: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 GAA03385 for ; Wed, 5 Sep 2001 06:47:51 -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 GAA22912; Wed, 5 Sep 2001 06:46:26 -0400 (EDT) Message-Id: <200109051046.GAA22912@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, 05 Sep 2001 06:46:25 -0400 Subject: [midcom] I-D ACTION:draft-molitor-midbox-telephony-topology-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 : Topology Considerations for IP Telephony MIDCOM Agents Author(s) : A. Molitor Filename : draft-molitor-midbox-telephony-topology-00.txt Pages : 10 Date : 04-Sep-01 This document describes several operational scenarios for IP Telephony and some ways in which a suitable MIDCOM Agent might interwork with one or more middleboxes to facilitate those scenarios. From these scenarios, certain minimum requirements for Agent knowledge of network topology will be derived. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-molitor-midbox-telephony-topology-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-molitor-midbox-telephony-topology-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-molitor-midbox-telephony-topology-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: <20010904141358.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-molitor-midbox-telephony-topology-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-molitor-midbox-telephony-topology-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010904141358.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 5 07:44: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 ESMTP id HAA25047 for ; Wed, 5 Sep 2001 07:44: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 HAA05529; Wed, 5 Sep 2001 07:38: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 HAA05499 for ; Wed, 5 Sep 2001 07:38:08 -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 ESMTP id HAA24765 for ; Wed, 5 Sep 2001 07:36:41 -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 f85Bbag13844 for ; Wed, 5 Sep 2001 12:37:36 +0100 (BST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Wed, 5 Sep 2001 12:37:16 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Sep 2001 12:37:15 +0100 Message-ID: <9154CB41F208D5118DD200508BE39C30445248@zjguc006.europe.nortel.com> From: "Cedric Aoun" To: "'Scott Brim'" , "Melinda Shore (E-mail)" , "Midcom IETF (E-mail)" Subject: RE: [midcom] unused states clean-up Date: Wed, 5 Sep 2001 12:37:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C135FF.1B0AA6A0" Sender: 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_01C135FF.1B0AA6A0 Content-Type: text/plain; charset="iso-8859-1" I support this decision, R23 should be the requirement. R6 and R81 are a "HOW TO" to for R23, therefore we can delete them. We'll go into the details on how to meet the requirement when we get rechartered. Cedric -----Original Message----- From: Scott Brim [mailto:swb@employees.org] Sent: Tuesday, September 04, 2001 8:19 PM To: Midcom IETF (E-mail) Subject: Re: [midcom] unused states clean-up On Tue, Sep 04, 2001 02:03:51PM -0400, Melinda Shore allegedly wrote: > At 10:57 AM 9/4/01 -0400, Scott Brim wrote: > >I don't think we ever resolved this in the main group > > We didn't. > > >I think > >we agree on the requirement, just not the solution, which we should put > >off. > > Is this a proposal to let R6 and R81 stand as is? My one caveat would > be that R6 does put a requirement on the behavior of the middlebox. No, I think they should be deleted in favor of the real, fundamental requirement, R23. Questions about specifics such as timers should be put off until the next incarnation of the WG. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C135FF.1B0AA6A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] unused states clean-up

I support this decision, R23 should be the = requirement.
R6 and R81 are a "HOW TO" to for R23, = therefore we can delete them.
We'll go into the details on how to meet the = requirement when we get rechartered.
Cedric

-----Original Message-----
From: Scott Brim [mailto:swb@employees.org]
Sent: Tuesday, September 04, 2001 8:19 PM
To: Midcom IETF (E-mail)
Subject: Re: [midcom] unused states clean-up


On Tue, Sep 04, 2001 02:03:51PM -0400, Melinda Shore = allegedly wrote:
> At 10:57 AM 9/4/01 -0400, Scott Brim = wrote:
> >I don't think we ever resolved this in the = main group
>
> We didn't.
>
> >I think
> >we agree on the requirement, just not the = solution, which we should put
> >off.
>
> Is this a proposal to let R6 and R81 stand as = is?  My one caveat would
> be that R6 does put a requirement on the = behavior of the middlebox.

No, I think they should be deleted in favor of the = real, fundamental
requirement, R23.  Questions about specifics = such as timers should be
put off until the next incarnation of the WG.

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

------_=_NextPart_001_01C135FF.1B0AA6A0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 5 10:29:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04531 for ; Wed, 5 Sep 2001 10:29:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10572; Wed, 5 Sep 2001 10:25: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 KAA10541 for ; Wed, 5 Sep 2001 10:25:46 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAB04286 for ; Wed, 5 Sep 2001 10:24:20 -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 f85EPG806988 for ; Wed, 5 Sep 2001 07:25:16 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp134.cisco.com [10.21.64.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACC05712; Wed, 5 Sep 2001 07:25:14 -0700 (PDT) Message-Id: <5.1.0.14.0.20010905102630.00a5f390@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 05 Sep 2001 10:26:57 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Topology considerations documents Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Now available at: http://www.ietf.org/internet-drafts/draft-molitor-midbox-telephony-topology-00.txt http://www.ietf.org/internet-drafts/draft-aoun-midcom-agent-information-00.txt http://www.acmepacket.com/internetdrafts/draft-penfield-midcom-realms-00.txt Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 5 10:58:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06123 for ; Wed, 5 Sep 2001 10:58: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 KAA11791; Wed, 5 Sep 2001 10:52: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 KAA11762 for ; Wed, 5 Sep 2001 10:52:32 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05703 for ; Wed, 5 Sep 2001 10:51:05 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f85Eq5825022 for ; Wed, 5 Sep 2001 07:52:05 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp134.cisco.com [10.21.64.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACC06277; Wed, 5 Sep 2001 07:51:58 -0700 (PDT) Message-Id: <5.1.0.14.0.20010905105322.00a62050@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 05 Sep 2001 10:53:41 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] R6, R81 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Deleted. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 5 11:02:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06378 for ; Wed, 5 Sep 2001 11:02: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 KAA12043; Wed, 5 Sep 2001 10:58: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 KAA12018 for ; Wed, 5 Sep 2001 10:58:16 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06038 for ; Wed, 5 Sep 2001 10:56:49 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f85EsnD11980 for ; Wed, 5 Sep 2001 07:55:29 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp134.cisco.com [10.21.64.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACC06390; Wed, 5 Sep 2001 07:56:41 -0700 (PDT) Message-Id: <5.1.0.14.0.20010905105508.00a5e4a0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 05 Sep 2001 10:58:23 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Terms needing definition or replacement Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Ruleset Pinhole Connection Pinhole-descriptor (the thing describing the state that's been created on the middlebox) flow/resource Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 5 11:14: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 ESMTP id LAA06926 for ; Wed, 5 Sep 2001 11:14: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 LAA12823; Wed, 5 Sep 2001 11:12: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 LAA12794 for ; Wed, 5 Sep 2001 11:12:46 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06816 for ; Wed, 5 Sep 2001 11:11:20 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A0E47B82011E; Wed, 05 Sep 2001 11:12:36 -0400 Message-ID: <00ed01c1361c$d320a240$2300000a@acmepacket.com> From: "Bob Penfield" To: , "Melinda Shore" References: <5.1.0.14.0.20010905102630.00a5f390@mira-sjc5-4.cisco.com> Subject: Re: [midcom] Topology considerations documents Date: Wed, 5 Sep 2001 11:09: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 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 The third one should be: http://www.ietf.org/internet-drafts/draft-penfield-midcom-realms-00.txt (-:bob ----- Original Message ----- From: "Melinda Shore" To: Sent: Wednesday, September 05, 2001 10:26 AM Subject: [midcom] Topology considerations documents > Now available at: > http://www.ietf.org/internet-drafts/draft-molitor-midbox-telephony-topology- 00.txt > http://www.ietf.org/internet-drafts/draft-aoun-midcom-agent-information-00.t xt > http://www.acmepacket.com/internetdrafts/draft-penfield-midcom-realms-00.txt > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 5 19:14: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 ESMTP id TAA24659 for ; Wed, 5 Sep 2001 19:14: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 TAA26438; Wed, 5 Sep 2001 19:09:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26409 for ; Wed, 5 Sep 2001 19:09:43 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24300 for ; Wed, 5 Sep 2001 19:08:18 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q131AMG1; Wed, 5 Sep 2001 19:09:12 -0400 Message-Id: <3.0.5.32.20010905190446.009db3e0@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 05 Sep 2001 19:04:46 -0400 To: Melinda Shore , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Terms needing definition or replacement In-Reply-To: <5.1.0.14.0.20010905105508.00a5e4a0@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 10:58 AM 9/5/01 -0400, Melinda Shore wrote: >Ruleset >Pinhole >Connection >Pinhole-descriptor (the thing describing the state that's been > created on the middlebox) >flow/resource > >Melinda Is that an invitation to propose terms/definitions? I thought someone got sent off from London to do that? Anyway, here is a proposal for 5 terms to obsolete the above ones. The first two describe phenomena that exist (already) in the network; the last three describe midcom artifacts. Microflow A single instance of an application-to-application flow of packets which is identified by source address, source port, destination address, destination port and protocol id. [[That is the definition from RFC 2475, Diffserv Arch.]] In a middlebox connected to multiple address realms with overlapping address spaces, some additional criterion besides the above-listed 5-tuple will be needed to uniquely identify a microflow. Application Flow The union of all microflows attributable to a single application session. The exact nature of this will vary with the application. Filter Spec Packet classifier information that identifies a set of packets to be treated a certain way by a middlebox. Depending on its value, a filter spec may refer to something as specific as a microflow originated in a certain direction, or as general as "all packets". [[Term adapted from rfc 2205 RSVP.]] Flow Spec Description of the middlebox treatment/service to be applied to a set of packets. May also contain auxilliary information such as timeout values, owning agent, etc. [[Term taken from rfc 2205 RSVP. Definition changed to be midcom-relevant.]] Flow Descriptor The combination of a filter spec and one or more flow specs. Packets matching the filter spec are to be treated according to the associated flow spec(s). [[Term adapted from rfc 2205 RSVP.]] _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 5 19:19:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24727 for ; Wed, 5 Sep 2001 19:19: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 TAA26561; Wed, 5 Sep 2001 19:18:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26532 for ; Wed, 5 Sep 2001 19:18:35 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24681 for ; Wed, 5 Sep 2001 19:15:59 -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 f85NGSv04671; Wed, 5 Sep 2001 16:16:28 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-164.cisco.com [10.21.112.164]) by airborne.cisco.com (Mirapoint) with SMTP id AAR29511; Wed, 5 Sep 2001 16:16:00 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Wed, 5 Sep 2001 19:15:59 -0400 Date: Wed, 5 Sep 2001 19:15:59 -0400 From: Scott Brim To: Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] Terms needing definition or replacement Message-ID: <20010905191558.A536@SBRIM-W2K> Mail-Followup-To: Scott Brim , Melinda Shore , midcom@ietf.org References: <5.1.0.14.0.20010905105508.00a5e4a0@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20010905105508.00a5e4a0@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Wed, Sep 05, 2001 at 10:58:23AM -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Wed, Sep 05, 2001 10:58:23AM -0400, Melinda Shore allegedly wrote: > Ruleset A set of rules which are installed and removed as a unit. A combination of a filtering (matching) specification and one or more action specifications. How complex these can be is not defined. (This is the generic I prefer. It's specific, it's not ambiguous, and it includes all the functions of all the others, e.g. pinhole). > Pinhole A ruleset where the main action specification is either to allow packets to traverse the middlebox or to allow it through with address and/or port translation. (If you want to keep using this word, I suggest separating out the two different kinds of pinholes. "translated" versus "straight-through" pinholes, maybe.) > Connection Rewrite to eliminate all occurrences of this word. Don't assume any state maintenance mechanism. > Pinhole-descriptor (the thing describing the state that's been > created on the middlebox) Ruleset. > flow/resource Eliminate. > Melinda ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 00:13: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 ESMTP id AAA00504 for ; Thu, 6 Sep 2001 00:13: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 AAA04069; Thu, 6 Sep 2001 00:11: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 AAA04036 for ; Thu, 6 Sep 2001 00:11:19 -0400 (EDT) Received: from mail.hl.cn (mail.hl.cn [202.97.224.113]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00453 for ; Thu, 6 Sep 2001 00:09:51 -0400 (EDT) Received: from mail.hl.cn([127.0.0.1]) by mail.hl.cn(JetMail 2.5.3.0) with SMTP id jm23b96fc43; Thu, 6 Sep 2001 03:57:46 -0000 Received: from loki.ietf.org([132.151.1.177]) by mail.hl.cn(JetMail 2.5.3.0) with SMTP id jm3b3b94c212; Tue, 4 Sep 2001 11:56:51 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA05674 for ietf-123-outbound.01@ietf.org; Tue, 4 Sep 2001 07:25:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA05343 for ; Tue, 4 Sep 2001 06:48:00 -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 GAA07195; Tue, 4 Sep 2001 06:47:58 -0400 (EDT) Message-Id: <200109041047.GAA07195@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 04 Sep 2001 06:47:58 -0400 Subject: [midcom] I-D ACTION:draft-aoun-midcom-agent-information-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 : Required Information in Midcom Agents Author(s) : C. Aoun, S. Sen Filename : draft-aoun-midcom-agent-information-00.txt Pages : 8 Date : 31-Aug-01 This draft is part of a gladiator contest within the MIDCOM WG to determine what network topology information is needed at the Midcom agent. By taking out application awareness from Middle Boxes in the networks, and keeping this application knowledge in the application devices (the Midcom Agents); sufficient information needs to be put in the Midcom Agent to allow them to fulfill their responsibility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-aoun-midcom-agent-information-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-aoun-midcom-agent-information-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-aoun-midcom-agent-information-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: <20010831125929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-aoun-midcom-agent-information-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-aoun-midcom-agent-information-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010831125929.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 00: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 ESMTP id AAA00955 for ; Thu, 6 Sep 2001 00: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 AAA04700; Thu, 6 Sep 2001 00:32: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 AAA04667 for ; Thu, 6 Sep 2001 00:31: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 ESMTP id AAA00874 for ; Thu, 6 Sep 2001 00:30:32 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id 457E28106 for ; Wed, 5 Sep 2001 23:29:53 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id XAA19405 for ; Wed, 5 Sep 2001 23:29:53 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Wed, 5 Sep 2001 23:29:52 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Topology considerations documents In-Reply-To: <5.1.0.14.0.20010905102630.00a5f390@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 Wed, 5 Sep 2001, Melinda Shore wrote: > Now available at: > http://www.ietf.org/internet-drafts/draft-molitor-midbox-telephony-topology-00.txt > http://www.ietf.org/internet-drafts/draft-aoun-midcom-agent-information-00.txt > http://www.acmepacket.com/internetdrafts/draft-penfield-midcom-realms-00.txt I have quickly perused the two of these I did NOT write, and I think the three authors are essentially in agreement. 1) some notion of 'realm' is needed which is roughly a set of IP addresses, except that some additional information is needed since privately addressed realms can easily have overlapping addresses. 2) The MIDCOM agent needs to figure out which realms are involved in any given session (whatever "session" means). How it figures this out is Out Of Scope. 3) By implication, the MIDCOM agent can deduce which middleboxes need to be configured and which interfaces (or equivalent) are involved. 4) It is therefore possible -- and also for security reasons necessary -- to add to a pure 5-tuple some information about interfaces expected to receive and transmit traffic belonging to the session. How this additional "interface" information is managed is up for grabs. You can apply a 5-tuple/NAT-binding/etc TO and interface, or you can specify interface information IN the 5-tuple/NAT bind/etc. There are probably more ways to do it. The terminology is all variable at this point, though I think Bob Penfield and I used the word "realm" in essentially the same way. Does this agree with what other people see in these documents? (in particular, of course, the authors!) Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 08:57:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24530 for ; Thu, 6 Sep 2001 08:57: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 IAA21284; Thu, 6 Sep 2001 08:53: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 IAA21252 for ; Thu, 6 Sep 2001 08:53:41 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24211 for ; Thu, 6 Sep 2001 08:52:14 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A1D3AF7A011E; Thu, 06 Sep 2001 08:53:39 -0400 Message-ID: <008101c136d2$26055400$2300000a@acmepacket.com> From: "Bob Penfield" To: "Andrew Molitor" , References: Subject: Re: [midcom] Topology considerations documents Date: Thu, 6 Sep 2001 08:47: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 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I agree that we four gladiators are in agreement. I think Cedric & Sanjoy's usage of the term "realm" is consistent with mine and Andrew's. Realm is the right term to use. The term "interface" can be too specific or not specific enough depending on the configuration of the middlebox, and it falls into the category of "too much information" as far as exposing topology to MIDCOM agents. The realm concept should be incorporated into the MIDCOM framework. I think it is already a part of the framework, it is just not explicitly called realm. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Andrew Molitor" To: Sent: Thursday, September 06, 2001 12:29 AM Subject: Re: [midcom] Topology considerations documents > > > On Wed, 5 Sep 2001, Melinda Shore wrote: > > > Now available at: > > http://www.ietf.org/internet-drafts/draft-molitor-midbox-telephony-topology- 00.txt > > http://www.ietf.org/internet-drafts/draft-aoun-midcom-agent-information-00.t xt > > http://www.acmepacket.com/internetdrafts/draft-penfield-midcom-realms-00.txt > > I have quickly perused the two of these I did NOT write, and I > think the three authors are essentially in agreement. > > 1) some notion of 'realm' is needed which is roughly a set of > IP addresses, except that some additional information is > needed since privately addressed realms can easily have > overlapping addresses. > > 2) The MIDCOM agent needs to figure out which realms are > involved in any given session (whatever "session" means). > How it figures this out is Out Of Scope. > > 3) By implication, the MIDCOM agent can deduce which middleboxes > need to be configured and which interfaces (or equivalent) > are involved. > > 4) It is therefore possible -- and also for security reasons > necessary -- to add to a pure 5-tuple some information about > interfaces expected to receive and transmit traffic belonging > to the session. > > How this additional "interface" information is managed is > up for grabs. You can apply a 5-tuple/NAT-binding/etc TO and interface, > or you can specify interface information IN the 5-tuple/NAT bind/etc. > There are probably more ways to do it. > > The terminology is all variable at this point, though I think > Bob Penfield and I used the word "realm" in essentially the same way. > > Does this agree with what other people see in these documents? > (in particular, of course, the authors!) > > Andrew > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 10:19:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28283 for ; Thu, 6 Sep 2001 10:19:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23803; Thu, 6 Sep 2001 10:17: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 KAA23777 for ; Thu, 6 Sep 2001 10:17:49 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28221 for ; Thu, 6 Sep 2001 10:16:22 -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 f86EHIx05406 for ; Thu, 6 Sep 2001 07:17:18 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-104.cisco.com [10.21.112.104]) by airborne.cisco.com (Mirapoint) with SMTP id AAR35556; Thu, 6 Sep 2001 07:17:17 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 6 Sep 2001 10:17:16 -0400 Date: Thu, 6 Sep 2001 10:17:16 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Terms needing definition or replacement Message-ID: <20010906101716.G1816@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <5.1.0.14.0.20010905105508.00a5e4a0@mira-sjc5-4.cisco.com> <3.0.5.32.20010905190446.009db3e0@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.20010905190446.009db3e0@email.quarrytech.com>; from mduffy@quarrytech.com on Wed, Sep 05, 2001 at 07:04:46PM -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Wed, Sep 05, 2001 07:04:46PM -0400, Mark Duffy allegedly wrote: > At 10:58 AM 9/5/01 -0400, Melinda Shore wrote: > >Ruleset > >Pinhole > >Connection > >Pinhole-descriptor (the thing describing the state that's been > > created on the middlebox) > >flow/resource > > > >Melinda > > Is that an invitation to propose terms/definitions? I thought someone > got sent off from London to do that? Anyway, here is a proposal for 5 > terms to obsolete the above ones. The first two describe phenomena > that exist (already) in the network; the last three describe midcom > artifacts. I've found that people generally have trouble getting used to RSVP terminology. In particular, it would seem intuitive that a "flow spec" should describ a flow, as opposed to a scheduling treatment of a flow. You've gone further and you're defining a flow spec as one or more rules for modifying/dropping the packets in a flow. It doesn't feel exactly intuitive. The phrase I'm used to is "transform rules". I made that a bit more intuitive in my proposal and suggested "action specifications". > Microflow A single instance of an application-to-application flow of > packets which is identified by source address, source port, destination > address, destination port and protocol id. [[That is the definition from > RFC 2475, Diffserv Arch.]] In a middlebox connected to multiple address > realms with overlapping address spaces, some additional criterion besides > the above-listed 5-tuple will be needed to uniquely identify a microflow. We've agreed that the midcom protocol will make it possible to define rules for 5-tuples as you describe them above, but that the protocol will not limit you to only being able to match 5-tuples. Even in diffserv, and in MPLS, classification at the edge is a separate issue from treatment in the network and can use any criteria it wants. A middlebox will act upon a set of packets which match a filter spec -- it won't (necessarily) work in units of microflows. So, what use is this definition for midcom? The only use I see is when we are presenting examples, so I suppose this will be useful in a framework document, but that's all. > Application Flow The union of all microflows attributable to a single > application session. The exact nature of this will vary with the application. Same. Good for examples. > Filter Spec Packet classifier information that identifies a set of > packets to be treated a certain way by a middlebox. Depending on its > value, a filter spec may refer to something as specific as a microflow > originated in a certain direction, or as general as "all packets". [[Term > adapted from rfc 2205 RSVP.]] OK. > Flow Spec Description of the middlebox treatment/service to be applied > to a set of packets. May also contain auxilliary information such as > timeout values, owning agent, etc. [[Term taken from rfc 2205 RSVP. > Definition changed to be midcom-relevant.]] > > Flow Descriptor The combination of a filter spec and one or more flow > specs. Packets matching the filter spec are to be treated according to the > associated flow spec(s). [[Term adapted from rfc 2205 RSVP.]] As I said above, the problem with these is that the terms suggest meanings other than the ones you've provided I assume you've read my suggestions. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 13:34: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 ESMTP id NAA03579 for ; Thu, 6 Sep 2001 13:34: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 NAA29065; Thu, 6 Sep 2001 13:31:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29036 for ; Thu, 6 Sep 2001 13:31:12 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03419 for ; Thu, 6 Sep 2001 13:29:45 -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 f86HUkp01481 for ; Thu, 6 Sep 2001 10:30:46 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-104.cisco.com [10.21.112.104]) by airborne.cisco.com (Mirapoint) with SMTP id AAR38651; Thu, 6 Sep 2001 10:30:34 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 6 Sep 2001 13:30:31 -0400 Date: Thu, 6 Sep 2001 13:30:31 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Topology considerations documents Message-ID: <20010906133030.A1764@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <008101c136d2$26055400$2300000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <008101c136d2$26055400$2300000a@acmepacket.com>; from bpenfield@acmepacket.com on Thu, Sep 06, 2001 at 08:47:53AM -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 Realms as a concept are useful. We speak of addressing realms (which have address spaces), and so on. The idea of instantiating these kinds of realms in any protocol disturbs me greatly. Bob proposes adding a realm ID to the midcom protocol. The realm ID would be for a "natural" space delineated by NATs/Firewalls. It would be unique among all the different realms a particular realm spoke to. If I understand correctly, it would not be carried in any particular application protocol, but would be derived from the e.g. TLS connection over which an invitation or whatever arrived. The other proposals seem to assume a realm identifier gets determined somehow. Whether it does or not, if you instantiate the *concept* of realms like this ... You need a universal namespace. Why universal? You only need to be distinct from those you communicate with, right? Well, it would be difficult to be sure that your realm ID was unique among every one you would have an association with, especially because a lot of SIP proxies will be in casually run organizations. Difficult enough that global uniqueness would be required to avoid overall pain. This isn't like routing, where you only communicate with your contiguous peers, so you can use "localized" and/or "temporary" realm identifiers. You never know when you're going to want to establish an association across half the Internet. There is no other universal namespace at this level that I can think. Even AS numbers are not unique, since some are temporary/local. Some people with NATs/firewalls don't even have temporary AS numbers. So AS numbers are out. Domain names are not topologically indicative, so they're out. This kind of namespace is completely new. Well, we used to try to have globally unique ASs and don't try anymore because we don't need them to be. What happens when realms split and merge? How will an agent know when two endpoints are inside and outside during splits and mergers? There's a strong chance for misconfiguration here, and you're betting the security of your network -- or your customers' networks -- on configuration to a greater extent than before, since errors won't become obvious until they are a security problem. Someone has to administer the namespace, as organizations do for domain names, and that will cost money. And politics! Man, the politics alone scare me. "Realms" for different applications cannot be depended on to be congruent. What do you do when you have different kinds of middleboxes with some intermediate nodes like web servers? So, if realms for different applications turn out not to be congruent, or if we want some more flexibility in the unknown future, you would need not just one globally unique identifier, but one for every class of agent! Setting up even the possibility of that happening is not good architecture. If you do carry realm IDs in application signaling, then you're going to have to change every existing application signaling protocol for which an agent might want to speak Midcom. OK, suppose you avoid globally unique identifiers by saying you'll just configure every agent with every possible peer that it should consider "inside". First you have to be sure that you'll always be able to determine whether a peer is inside or outside. That puts a lot of restrictions on how we develop our application signaling in the future (and I'm not even sure we could make that claim today). Second, you still have a serious synchronization problem, a serious maintenance problem for service providers, and the possibility of opening up unnoticed security holes. So globally unique identifiers feels like it has all sorts of problems, and implicit classification of peers is also painful. If I've understood how you all want to use realm identifiers, then -- I'm sorry to say, really -- I don't think this is a path we or the rest of the IETF will want to progress down -- it's just not good scalable engineering. I have some ideas which I wasn't able to get written up before the deadline, but I will ASAP. The WG established the deadline as a tool for making progress. I don't like saying it but I don't call this progress yet. If we say the working group has no choice but to accept what came in before the deadline, we're treating procedure as sacred and forgetting that utility of the outcome is the only useful measure of success. Anyway, I'm writing now. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 14:51:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05990 for ; Thu, 6 Sep 2001 14:51: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 OAA01338; Thu, 6 Sep 2001 14:45: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 OAA01309 for ; Thu, 6 Sep 2001 14:45:06 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05700 for ; Thu, 6 Sep 2001 14:43:39 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A42FA77E014C; Thu, 06 Sep 2001 14:45:03 -0400 Message-ID: <007401c13702$d7b96bc0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Scott Brim" , References: <008101c136d2$26055400$2300000a@acmepacket.com> <20010906133030.A1764@SBRIM-W2K> Subject: Re: [midcom] Topology considerations documents Date: Thu, 6 Sep 2001 14:36:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I see a realm names/identifiers as belonging to a particular middlebox or group of middleboxes. Relationships between MIDCOM agents and middleboxes will be based on business and/or contractual relationships and will not be established willy nilly half way across the Internet. Middleboxes that do firewall and NAT live at the borders of networks. A midcom agents that control those middleboxes will live in the networks that the middleboxes are the at the border of. The realm naming scheme, if they need realms at all, will be worked out between the parties that own the networks. There is no need for a universal namespace for realms. How the midcom agents learn the realm names is not a midcom problem. It could be through static configuration or some discovery protocol between the entities sharing that realm naming scheme and namespace. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Scott Brim" To: Sent: Thursday, September 06, 2001 1:30 PM Subject: Re: [midcom] Topology considerations documents > Realms as a concept are useful. We speak of addressing realms (which > have address spaces), and so on. The idea of instantiating these kinds > of realms in any protocol disturbs me greatly. > > Bob proposes adding a realm ID to the midcom protocol. The realm ID > would be for a "natural" space delineated by NATs/Firewalls. It would > be unique among all the different realms a particular realm spoke to. > If I understand correctly, it would not be carried in any particular > application protocol, but would be derived from the e.g. TLS connection > over which an invitation or whatever arrived. > > The other proposals seem to assume a realm identifier gets determined > somehow. Whether it does or not, if you instantiate the *concept* of > realms like this ... > > You need a universal namespace. Why universal? You only need to be > distinct from those you communicate with, right? Well, it would be > difficult to be sure that your realm ID was unique among every one you > would have an association with, especially because a lot of SIP proxies > will be in casually run organizations. Difficult enough that global > uniqueness would be required to avoid overall pain. This isn't like > routing, where you only communicate with your contiguous peers, so you > can use "localized" and/or "temporary" realm identifiers. You never > know when you're going to want to establish an association across half > the Internet. > > There is no other universal namespace at this level that I can think. > Even AS numbers are not unique, since some are temporary/local. Some > people with NATs/firewalls don't even have temporary AS numbers. So AS > numbers are out. Domain names are not topologically indicative, so > they're out. This kind of namespace is completely new. Well, we used > to try to have globally unique ASs and don't try anymore because we > don't need them to be. > > What happens when realms split and merge? How will an agent know when > two endpoints are inside and outside during splits and mergers? There's > a strong chance for misconfiguration here, and you're betting the > security of your network -- or your customers' networks -- on > configuration to a greater extent than before, since errors won't become > obvious until they are a security problem. > > Someone has to administer the namespace, as organizations do for domain > names, and that will cost money. And politics! Man, the politics alone > scare me. > > "Realms" for different applications cannot be depended on to be > congruent. What do you do when you have different kinds of middleboxes > with some intermediate nodes like web servers? So, if realms for > different applications turn out not to be congruent, or if we want some > more flexibility in the unknown future, you would need not just one > globally unique identifier, but one for every class of agent! Setting > up even the possibility of that happening is not good architecture. > > If you do carry realm IDs in application signaling, then you're going to > have to change every existing application signaling protocol for which > an agent might want to speak Midcom. > > OK, suppose you avoid globally unique identifiers by saying you'll just > configure every agent with every possible peer that it should consider > "inside". First you have to be sure that you'll always be able to > determine whether a peer is inside or outside. That puts a lot of > restrictions on how we develop our application signaling in the future > (and I'm not even sure we could make that claim today). Second, you > still have a serious synchronization problem, a serious maintenance > problem for service providers, and the possibility of opening up > unnoticed security holes. > > So globally unique identifiers feels like it has all sorts of problems, > and implicit classification of peers is also painful. > > If I've understood how you all want to use realm identifiers, then -- > I'm sorry to say, really -- I don't think this is a path we or the rest > of the IETF will want to progress down -- it's just not good scalable > engineering. > > I have some ideas which I wasn't able to get written up before the > deadline, but I will ASAP. The WG established the deadline as a tool > for making progress. I don't like saying it but I don't call this > progress yet. If we say the working group has no choice but to accept > what came in before the deadline, we're treating procedure as sacred and > forgetting that utility of the outcome is the only useful measure of > success. Anyway, I'm writing now. > > ..Scott > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 16:44:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08625 for ; Thu, 6 Sep 2001 16:44: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 QAA04397; Thu, 6 Sep 2001 16:40: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 QAA04363 for ; Thu, 6 Sep 2001 16:40:11 -0400 (EDT) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08237 for ; Thu, 6 Sep 2001 16:38:43 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 39D708211 for ; Thu, 6 Sep 2001 15:39:56 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id PAA29090 for ; Thu, 6 Sep 2001 15:39:52 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Thu, 6 Sep 2001 15:39:52 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Topology considerations documents In-Reply-To: <007401c13702$d7b96bc0$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 For my money, "realm" is a useful construct to think about, but it is not a MIDCOM construct. My way of thinking of this is that Agents will have "some notion of realms" which the Agent will use to compute some notion of or similar to interfaces. It is this notion of interfaces that appears in MIDCOM messaging. It is, in my opinion, ludicrous to propose that a middlebox should possess anything resembling global knowledge. The whole point is to make a DUMB middlebox, that could easily know nothing more than what physical interfaces it has, and internal policy/NAT state. In particular it might very well not have any concept of IP routing. Also, by implication, it knows nothing of realms. If you equate a realm to "the stuff off that interface" why not call a spade a spade and admit that we're talking about interfaces, not realms! In summary: realms are, roughly, the coarse notion of network topology used by the AGENT to compute interface information. This interface information is communicated via MIDCOM to the MIDDLEBOX, which itself may well have not concept of realm. Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 17: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 ESMTP id RAA09280 for ; Thu, 6 Sep 2001 17:19: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 RAA05484; Thu, 6 Sep 2001 17:18: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 RAA05455 for ; Thu, 6 Sep 2001 17:18: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 ESMTP id RAA09221 for ; Thu, 6 Sep 2001 17:16:38 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q131AP17; Thu, 6 Sep 2001 17:17:35 -0400 Message-Id: <3.0.5.32.20010906171650.00a1d860@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 06 Sep 2001 17:16:50 -0400 To: "Bob Penfield" , "Scott Brim" , From: Mark Duffy Subject: Re: [midcom] Topology considerations documents In-Reply-To: <007401c13702$d7b96bc0$2300000a@acmepacket.com> References: <008101c136d2$26055400$2300000a@acmepacket.com> <20010906133030.A1764@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 My understanding is similar to what Bob has stated. The realm identifiers only need to be unique within the middlebox that the midcom request is directed to. The point of all the gladiators' drafts is (I think) that the agent must know which middlebox it needs to send a particular request to, and must know which of the realms connected to that middlebox to tell the middlebox each pinhole/etc. request relates to. -Mark At 02:36 PM 9/6/01 -0400, Bob Penfield wrote: >I see a realm names/identifiers as belonging to a particular middlebox or >group of middleboxes. Relationships between MIDCOM agents and middleboxes >will be based on business and/or contractual relationships and will not be >established willy nilly half way across the Internet. Middleboxes that do >firewall and NAT live at the borders of networks. A midcom agents that >control those middleboxes will live in the networks that the middleboxes are >the at the border of. > >The realm naming scheme, if they need realms at all, will be worked out >between the parties that own the networks. There is no need for a universal >namespace for realms. > >How the midcom agents learn the realm names is not a midcom problem. It >could be through static configuration or some discovery protocol between the >entities sharing that realm naming scheme and namespace. > >(-:bob _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 17:40:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09579 for ; Thu, 6 Sep 2001 17:40: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 RAA05993; Thu, 6 Sep 2001 17:36: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 RAA05967 for ; Thu, 6 Sep 2001 17:36:00 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09509 for ; Thu, 6 Sep 2001 17:34:34 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q131APG3; Thu, 6 Sep 2001 17:35:30 -0400 Message-Id: <3.0.5.32.20010906173442.00a05a80@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 06 Sep 2001 17:34:42 -0400 To: Andrew Molitor , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Topology considerations documents In-Reply-To: References: <007401c13702$d7b96bc0$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 Andrew, yes there are middleboxes that want to be told what interface a pinhole/etc should be applied to. A traditional 2-interface firewall comes to mind. But there are other middleboxes that have more complex models -- for example, multiple interfaces into each administrative realm, or multiple realms reached via the same interface. By using the more abstract concept of realm rather than interface, one has a model powerful enough to manage both these types of devices, not just the simpler one. --Mark At 03:39 PM 9/6/01 -0500, Andrew Molitor wrote: > For my money, "realm" is a useful construct to think about, >but it is not a MIDCOM construct. My way of thinking of this is >that Agents will have "some notion of realms" which the Agent will >use to compute some notion of or similar to interfaces. It is this >notion of interfaces that appears in MIDCOM messaging. > > It is, in my opinion, ludicrous to propose that a middlebox >should possess anything resembling global knowledge. The whole >point is to make a DUMB middlebox, that could easily know nothing >more than what physical interfaces it has, and internal policy/NAT >state. > > In particular it might very well not have any concept of >IP routing. Also, by implication, it knows nothing of realms. If >you equate a realm to "the stuff off that interface" why not call >a spade a spade and admit that we're talking about interfaces, not >realms! > > In summary: > > realms are, roughly, the coarse notion of network topology > used by the AGENT to compute interface information. This > interface information is communicated via MIDCOM to the > MIDDLEBOX, which itself may well have not concept of realm. > > Andrew > > > >_______________________________________________ >midcom mailing list >midcom@ietf.org >http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 17:53: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 ESMTP id RAA09795 for ; Thu, 6 Sep 2001 17:53: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 RAA06194; Thu, 6 Sep 2001 17:46: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 RAA06167 for ; Thu, 6 Sep 2001 17:46:04 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09649 for ; Thu, 6 Sep 2001 17:44:37 -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 f86Ljgv12013; Thu, 6 Sep 2001 14:45:51 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-104.cisco.com [10.21.112.104]) by airborne.cisco.com (Mirapoint) with SMTP id AAS00759; Thu, 6 Sep 2001 14:45:08 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 6 Sep 2001 17:45:06 -0400 Date: Thu, 6 Sep 2001 17:45:05 -0400 From: Scott Brim To: Mark Duffy Cc: Bob Penfield , midcom@ietf.org Subject: Re: [midcom] Topology considerations documents Message-ID: <20010906174505.E1436@SBRIM-W2K> Mail-Followup-To: Scott Brim , Mark Duffy , Bob Penfield , midcom@ietf.org References: <008101c136d2$26055400$2300000a@acmepacket.com> <20010906133030.A1764@SBRIM-W2K> <007401c13702$d7b96bc0$2300000a@acmepacket.com> <3.0.5.32.20010906171650.00a1d860@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.20010906171650.00a1d860@email.quarrytech.com>; from mduffy@quarrytech.com on Thu, Sep 06, 2001 at 05:16:50PM -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Thu, Sep 06, 2001 05:16:50PM -0400, Mark Duffy allegedly wrote: > My understanding is similar to what Bob has stated. The realm identifiers > only need to be unique within the middlebox that the midcom request is > directed to. The point of all the gladiators' drafts is (I think) that > the agent must know which middlebox it needs to send a particular request > to, and must know which of the realms connected to that middlebox to tell > the middlebox each pinhole/etc. request relates to. How will a particular agent find out what realm identifiers a middlebox is using to name its attached realms, and whether those realms are inside or outside the trust/addressing boundaries? Configuration? Again you have management problems and potential security problems (as already discussed -- I'd rather not repeat it). Remember there are users out there, and we must not, in any way, insist on their getting configuration right. How about ... a global namespace and modification of all application signaling? Do you have any other alternatives? Pardon me for being short, it's late. I'm hoping you see what I'm saying without my having to elaborate. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 17:57: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 ESMTP id RAA09863 for ; Thu, 6 Sep 2001 17:57: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 RAA06426; Thu, 6 Sep 2001 17:53: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 RAA06396 for ; Thu, 6 Sep 2001 17:53:00 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09778 for ; Thu, 6 Sep 2001 17:51:33 -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 f86Lqep22810 for ; Thu, 6 Sep 2001 14:52:40 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-104.cisco.com [10.21.112.104]) by airborne.cisco.com (Mirapoint) with SMTP id AAS00895; Thu, 6 Sep 2001 14:52:27 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 6 Sep 2001 17:52:24 -0400 Date: Thu, 6 Sep 2001 17:52:24 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Topology considerations documents Message-ID: <20010906175224.F1436@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <007401c13702$d7b96bc0$2300000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from amolitor@visi.com on Thu, Sep 06, 2001 at 03:39:52PM -0500 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Thu, Sep 06, 2001 03:39:52PM -0500, Andrew Molitor allegedly wrote: > For my money, "realm" is a useful construct to think about, > but it is not a MIDCOM construct. My way of thinking of this is > that Agents will have "some notion of realms" which the Agent will > use to compute some notion of or similar to interfaces. It is this > notion of interfaces that appears in MIDCOM messaging. Just so you notice, this is different from what Mark just said, which is that the notion of realms is local to the middlebox (not the agent). Right, I saw that you said that. So, how does the agent classify an interaction into a realm? Well, I hesitate to repeat what I sent before but I don't see any scalable *and* manageable way to do it. I'll repeat myself tomorrow :-). _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 18:05: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 ESMTP id SAA09996 for ; Thu, 6 Sep 2001 18:05: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 SAA06875; Thu, 6 Sep 2001 18:05: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 SAA06843 for ; Thu, 6 Sep 2001 18:04: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 ESMTP id SAA09964 for ; Thu, 6 Sep 2001 18:03:27 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id D58A08224 for ; Thu, 6 Sep 2001 17:04:53 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id RAA04307 for ; Thu, 6 Sep 2001 17:04:53 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Thu, 6 Sep 2001 17:04:53 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Topology considerations documents In-Reply-To: <20010906175224.F1436@SBRIM-W2K> 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, 6 Sep 2001, Scott Brim wrote: > Right, I saw that you said that. So, how does the agent classify an > interaction into a realm? Well, I hesitate to repeat what I sent before > but I don't see any scalable *and* manageable way to do it. I'll repeat > myself tomorrow :-). Oh, I concur completely. This is a hard problem to solve. Luckily, it's totally out of scope for MIDCOM so we don't have to worry about it, at least not directly. At any rate, this is how I see the scope. I certainly remember nothing about being chartered to invent either a global realm namespace or a (local) realm naming convention. I maintain that the MIDCOM protocol needs to adorn 5-tuples with interface identifiers or equivalent, and that the realm discussion and toplogy discussion serves to prove that (in addition to providing useful context). At the end of the day, though, the only in-scope result is 'hey, interfaces!' If you REALLY want to use realm names instead of interface names in MIDCOM messages, please provide a real, useful example where this would be a) useful b) not isomorphic to interface names Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 18:10:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10062 for ; Thu, 6 Sep 2001 18:10: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 SAA06927; Thu, 6 Sep 2001 18:06: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 SAA06899 for ; Thu, 6 Sep 2001 18:06:26 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09990 for ; Thu, 6 Sep 2001 18:04:59 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A3622E0E011E; Thu, 06 Sep 2001 18:06:26 -0400 Message-ID: <001d01c1371e$aa901380$2300000a@acmepacket.com> From: "Bob Penfield" To: "Andrew Molitor" , , "Mark Duffy" References: <007401c13702$d7b96bc0$2300000a@acmepacket.com> <3.0.5.32.20010906173442.00a05a80@email.quarrytech.com> Subject: Re: [midcom] Topology considerations documents Date: Thu, 6 Sep 2001 17:55: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 For any given implementation, realm ID and interface ID could be the same thing. To the agent it is just a handle representing the realm. The middlebox knows exactly what that handle means. It might mean a specific interface, a group of interfaces, or one of several VLANs on a specific interface. (-:bob ----- Original Message ----- From: "Mark Duffy" To: "Andrew Molitor" ; Sent: Thursday, September 06, 2001 5:34 PM Subject: Re: [midcom] Topology considerations documents > Andrew, yes there are middleboxes that want to be told what interface a > pinhole/etc should be applied to. A traditional 2-interface firewall comes > to mind. But there are other middleboxes that have more complex models -- > for example, multiple interfaces into each administrative realm, or > multiple realms reached via the same interface. By using the more abstract > concept of realm rather than interface, one has a model powerful enough to > manage both these types of devices, not just the simpler one. --Mark > > > At 03:39 PM 9/6/01 -0500, Andrew Molitor wrote: > > For my money, "realm" is a useful construct to think about, > >but it is not a MIDCOM construct. My way of thinking of this is > >that Agents will have "some notion of realms" which the Agent will > >use to compute some notion of or similar to interfaces. It is this > >notion of interfaces that appears in MIDCOM messaging. > > > > It is, in my opinion, ludicrous to propose that a middlebox > >should possess anything resembling global knowledge. The whole > >point is to make a DUMB middlebox, that could easily know nothing > >more than what physical interfaces it has, and internal policy/NAT > >state. > > > > In particular it might very well not have any concept of > >IP routing. Also, by implication, it knows nothing of realms. If > >you equate a realm to "the stuff off that interface" why not call > >a spade a spade and admit that we're talking about interfaces, not > >realms! > > > > In summary: > > > > realms are, roughly, the coarse notion of network topology > > used by the AGENT to compute interface information. This > > interface information is communicated via MIDCOM to the > > MIDDLEBOX, which itself may well have not concept of realm. > > > > Andrew > > > > > > > >_______________________________________________ > >midcom mailing list > >midcom@ietf.org > >http://www1.ietf.org/mailman/listinfo/midcom > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 18:32:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10433 for ; Thu, 6 Sep 2001 18:32: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 SAA07727; Thu, 6 Sep 2001 18:30: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 SAA07697 for ; Thu, 6 Sep 2001 18:30:17 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10342 for ; Thu, 6 Sep 2001 18:28:50 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q131AP3D; Thu, 6 Sep 2001 18:29:47 -0400 Message-Id: <3.0.5.32.20010906182901.009cd100@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 06 Sep 2001 18:29:01 -0400 To: Andrew Molitor , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Topology considerations documents In-Reply-To: References: <20010906175224.F1436@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 05:04 PM 9/6/01 -0500, Andrew Molitor wrote: ... > I maintain that the MIDCOM protocol needs to adorn 5-tuples >with interface identifiers or equivalent, and that the realm discussion >and toplogy discussion serves to prove that (in addition to providing >useful context). At the end of the day, though, the only in-scope >result is 'hey, interfaces!' > > If you REALLY want to use realm names instead of interface >names in MIDCOM messages, please provide a real, useful example >where this would be > > a) useful > b) not isomorphic to interface names > > Andrew I will argue that "interface identifiers" are going in the right direction but are not general enough. Here is one counterexample that actually exists, it is not just something I have invented to argue this point. Picture a carrier-based middlebox that can provide a firewall service independently to multiple enterprises. Assume that it is possible that multiple enterprises A, B, and C may be connected to this middlebox *via the same interface* of the middlebox. A certain pinhole is to be opened for packets being sent to enterprise A, but not for those forwarded to B or C. To control this via midcom, "interface" is not a powerful enough criterion. "Realm", which is more general, is. > a) useful Yes, since it allows midcom to control this firewall > b) not isomorphic to interface names Yes, because in this case realm::interface is many::one -Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 18:56:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10997 for ; Thu, 6 Sep 2001 18:56: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 SAA08468; Thu, 6 Sep 2001 18:47:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08375 for ; Thu, 6 Sep 2001 18:47:04 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10792 for ; Thu, 6 Sep 2001 18:45:37 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q131APQZ; Thu, 6 Sep 2001 18:46:34 -0400 Message-Id: <3.0.5.32.20010906184545.009d9a00@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 06 Sep 2001 18:45:45 -0400 To: Scott Brim , Mark Duffy From: Mark Duffy Subject: Re: [midcom] Topology considerations documents Cc: Bob Penfield , midcom@ietf.org In-Reply-To: <20010906174505.E1436@SBRIM-W2K> References: <3.0.5.32.20010906171650.00a1d860@email.quarrytech.com> <008101c136d2$26055400$2300000a@acmepacket.com> <20010906133030.A1764@SBRIM-W2K> <007401c13702$d7b96bc0$2300000a@acmepacket.com> <3.0.5.32.20010906171650.00a1d860@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi Scott, see comments interspersed below... At 05:45 PM 9/6/01 -0400, Scott Brim wrote: >On Thu, Sep 06, 2001 05:16:50PM -0400, Mark Duffy allegedly wrote: >> My understanding is similar to what Bob has stated. The realm identifiers >> only need to be unique within the middlebox that the midcom request is >> directed to. The point of all the gladiators' drafts is (I think) that >> the agent must know which middlebox it needs to send a particular request >> to, and must know which of the realms connected to that middlebox to tell >> the middlebox each pinhole/etc. request relates to. > >How will a particular agent find out what realm identifiers a middlebox >is using to name its attached realms, MD-> I don't know for sure. Probably by configuration. The question doesn't bother me too much because I think the *same* question would need to be asked if using interface identifiers rather than realm identifiers. I.e. How does the agent know how the middlebox names its interfaces, and which ones are connected to where? > and whether those realms are >inside or outside the trust/addressing boundaries? Configuration? MD-> Again, the agent needs to know whether the 'sides' of the middlebox are in/out of a given trust boundary, whether those 'sides' are denominated as "interfaces" or "realms". And the agent needs to communicate that to the middlebox through midcom. It's just a matter of the granularity with which the world is broken into realms by the middlebox. I don't think the agent should care what that granularity is, other than using the appropriate syntax to name the realms over the wire in the midcom protocol. >Again you have management problems and potential security problems (as >already discussed -- I'd rather not repeat it). Remember there are >users out there, and we must not, in any way, insist on their getting >configuration right. How about ... a global namespace and modification >of all application signaling? MD-> Obviously, global namespace and modification of all application signaling is out of the question. I do think the agent needs to know the names of *something* (interfaces/realms/sides/domains/whatever) that the middlebox works against, and be able to specify them to the middlebox. I'm just trying to prevent midcom from embodying an assumption that for all middleboxes, domain==interface. >Do you have any other alternatives? > >Pardon me for being short, it's late. I'm hoping you see what I'm >saying without my having to elaborate. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 18:59: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 ESMTP id SAA11031 for ; Thu, 6 Sep 2001 18:59: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 SAA08302; Thu, 6 Sep 2001 18:43: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 SAA08271 for ; Thu, 6 Sep 2001 18:43:54 -0400 (EDT) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10614 for ; Thu, 6 Sep 2001 18:42:27 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 6CBF381C0 for ; Thu, 6 Sep 2001 17:43:54 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id RAA06117 for ; Thu, 6 Sep 2001 17:43:54 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Thu, 6 Sep 2001 17:43:54 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Topology considerations documents In-Reply-To: <3.0.5.32.20010906182901.009cd100@email.quarrytech.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, 6 Sep 2001, Mark Duffy wrote: > At 05:04 PM 9/6/01 -0500, Andrew Molitor wrote: > > If you REALLY want to use realm names instead of interface > >names in MIDCOM messages, please provide a real, useful example > >where this would be > > > > a) useful > > b) not isomorphic to interface names > > > > Andrew > > Picture a carrier-based middlebox that can provide a firewall service > independently to multiple enterprises. Assume that it is possible that > multiple enterprises A, B, and C may be connected to this middlebox *via > the same interface* of the middlebox. A certain pinhole is to be opened > for packets being sent to enterprise A, but not for those forwarded to B or > C. To control this via midcom, "interface" is not a powerful enough > criterion. "Realm", which is more general, is. > > > a) useful > Yes, since it allows midcom to control this firewall > > > b) not isomorphic to interface names > Yes, because in this case realm::interface is many::one What an excellent example! How would a middlebox identify the source and target realms of a specific packet? I can think of some schemes using IP addresses or the various and sundry Tags which can be shoved in packets. I am happy to stipulate that this is a middlebox specific problem, and we may assume that every packet is Somehow classified, and has a Source Realm and a Target Realm attached to it before policy is applied. One COULD make the case that this is just a fancied-up interface, but I think it's fair to abstract it and call it something else. I tend to think of realms as bigger, less local objects. E.G. Realm A -middlebox-+ | [ big network ]-- middlebox --[ big network ]-- Many Realms | Realm B -middlebox-+ In this case, the middlebox in the center doesn't care about Realm A versus Realm B, though an Agent trying to manage all the middleboxes for a SIP call might. The middlebox in the center only cares about "Realm Everything to the Left" and "Realm Everything to the Right" and THESE are the indications that need to get sent to it over MIDCOM. These are also the "Realm" names that get attached to packets as they pass through that middlebox. Would it be just too awful to use phrase "Global Realm" and "Local Realm" where this distinction is needed? Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 19:12:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11473 for ; Thu, 6 Sep 2001 19:12: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 TAA09212; Thu, 6 Sep 2001 19:06: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 TAA09185 for ; Thu, 6 Sep 2001 19:06:27 -0400 (EDT) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11187 for ; Thu, 6 Sep 2001 19:05:01 -0400 (EDT) Received: from 157.54.7.67 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 Sep 2001 16:04:19 -0700 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); Thu, 6 Sep 2001 16:04:19 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 6 Sep 2001 16:04:19 -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); Thu, 6 Sep 2001 16:03:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Topology considerations documents Date: Thu, 6 Sep 2001 16:03:49 -0700 Message-ID: Thread-Topic: [midcom] Topology considerations documents Thread-Index: AcE3I8h/kJooGW1uRN6FliLv2a3gOAAAZfSA From: "Christian Huitema" To: X-OriginalArrivalTime: 06 Sep 2001 23:03:49.0308 (UTC) FILETIME=[3062B7C0:01C13728] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA09186 Sender: 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 have read all three drafts, and have these feelings that we are well on our way to define a camel... I would like a different analysis, starting with the simplest topology and extending to the more complex topologies envisaged in the draft. I guess we all agree that the simplest topology is that of the "basic firewall" configuration: a protected domain that we can call "the interior", and by opposition a non protected side that we can call "the exterior". The concept of interior and exterior leads us in this case to a very simple pinhole specification. The pinhole is identified by: Interior address Protocol type Interior port Exterior address Exterior port Indeed, each of these values can be wildcarded, or maybe replaced by a "prefix" in the case of addresses. The pinhole will then have attributes, such as: Direction: send, recv, sendrecv, closed Mapping of the interior address to the outside, if NAT Maybe mapping of the exterior address on the inside Etc. A very good outcome of the directionality, i.e. from the inside out, is that we can order the list of pinholes, as if the 5 tuple was one big number. This allows us to define unambiguously which pinhole is most specifically matching a given packet header -- i.e., in the matching list, the one that comes first in the ordering, assuming that wildcards rank after specified values. OK, so we have a cool simple solution for the simple case, so what about the complex case, for example the case quoted in draft-penfield-midcom-realms-00.txt in which a single box protects several networks: +-------------+ | | +------+ | Customer A | | | +---------------+ | +-----------+ | | | | 10.0.0.x | | | | | | | | | | Service | +-------------+ |Middle| | Provider | | Box +------+ | +-------------+ | | | | | | | | | 192.168.20.x | | Customer B | | | | | | +-----------+ | +---------------+ | 10.0.0.x | | | | | +------+ +-------------+ Well, we may observe that such constructs are by and large equivalent to a multiple-box construct: +-------------+ | | +------+ | Customer A | | | +---------------+ | +-----------+ MB-A | | | | 10.0.0.x | | | | | | | +......+ | Service | +-------------+ . . | Provider | . +------+ | +-------------+ . . | | | | +......+ | 192.168.20.x | | Customer B | | | | | | +-----------+ MB-B | +---------------+ | 10.0.0.x | | | | | +------+ +-------------+ We don't want to split the hardware, but nothing prevents us from adopting a logical view in which "MB-A" and "MB-B" are different "midcom servers", i.e. have different logical names. So, if an agent wants to open a port for A, it sends comment to the midcom server "MB-A", and to "MB-B" if it wants to open a port for B. Pretty soon, we have a generic mechanism with a clear naming rule -- a name associated with the protected domain -- and a simple semantic -- interior and exterior. Looks nice, uh? -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 19:18: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 ESMTP id TAA11559 for ; Thu, 6 Sep 2001 19:18: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 TAA09506; Thu, 6 Sep 2001 19:16: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 TAA09477 for ; Thu, 6 Sep 2001 19:16:06 -0400 (EDT) Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11520 for ; Thu, 6 Sep 2001 19:14:40 -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 f86MQjW12846; Thu, 6 Sep 2001 15:27:21 -0700 Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Sep 2001 16:10:58 -0700 Message-ID: From: John LaCour To: "'Andrew Molitor'" , midcom@ietf.org Subject: RE: [midcom] Topology considerations documents Date: Thu, 6 Sep 2001 16:13:11 -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 > > Picture a carrier-based middlebox that can provide a > firewall service > > independently to multiple enterprises. Assume that it is > possible that > > multiple enterprises A, B, and C may be connected to this > middlebox *via > > the same interface* of the middlebox. A certain pinhole is > to be opened > > for packets being sent to enterprise A, but not for those > forwarded to B or > > C. To control this via midcom, "interface" is not a powerful enough > > criterion. "Realm", which is more general, is. > > > > > a) useful > > Yes, since it allows midcom to control this firewall > > > > > b) not isomorphic to interface names > > Yes, because in this case realm::interface is many::one Actually, it can also be one::many as well as many::one. Consider a single Access List applied to multiple interfaces. > I can think of some schemes using IP addresses > or the various and sundry Tags which can be shoved in packets. I > am happy to stipulate that this is a middlebox specific problem, > and we may assume that every packet is Somehow classified, and > has a Source Realm and a Target Realm attached to it before policy > is applied. Which packets get associated with which realms is a middlebox implementation problem not a MIDCOM problem. Some things that implementors might use to solve the middlebox problem, by way of example, include 802.1q tags, which interface a packet arrives on, what the src mac address is, etc. The key thing here is that MIDCOM should communicate changes to security policy in a specified realm. MIDCOM should not try to communicate which realm certain traffic/flows/packets belong to. -John _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 19:21:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11689 for ; Thu, 6 Sep 2001 19:21:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA09586; Thu, 6 Sep 2001 19:17: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 TAA09555 for ; Thu, 6 Sep 2001 19:17:25 -0400 (EDT) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11546 for ; Thu, 6 Sep 2001 19:16:00 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 8913081C0 for ; Thu, 6 Sep 2001 18:17:25 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id SAA07788 for ; Thu, 6 Sep 2001 18:17:25 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Thu, 6 Sep 2001 18:17:25 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] Topology considerations documents 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, 6 Sep 2001, Christian Huitema wrote: > Well, we may observe that such constructs are by and large equivalent to > a multiple-box construct: > > +-------------+ > | | +------+ > | Customer A | | | +---------------+ > | +-----------+ MB-A | | | > | 10.0.0.x | | | | | > | | +......+ | Service | > +-------------+ . . | Provider | > . +------+ | > +-------------+ . . | | > | | +......+ | 192.168.20.x | > | Customer B | | | | | > | +-----------+ MB-B | +---------------+ > | 10.0.0.x | | | > | | +------+ > +-------------+ > > We don't want to split the hardware, but nothing prevents us from > adopting a logical view in which "MB-A" and "MB-B" are different "midcom > servers", i.e. have different logical names. So, if an agent wants to > open a port for A, it sends comment to the midcom server "MB-A", and to > "MB-B" if it wants to open a port for B. Pretty soon, we have a generic > mechanism with a clear naming rule -- a name associated with the > protected domain -- and a simple semantic -- interior and exterior. > > Looks nice, uh? It looks beautiful. How does the physical middlebox tell which logical middlebox a given packet belongs to when it arrives on an interface? Also, what problem, precisely, is solved by including a logical middlebox name in, say, a pinhole description sent via MIDCOM? So far we have these ways to adorn 5-tuples and, in general, policy: - interface names - "Local Realm" names - logical middlebox names (presumably plus one of the earlier two since the logical middlebox doesn't do anything for directionality) Ain't it cool? _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 19:25: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 ESMTP id TAA11737 for ; Thu, 6 Sep 2001 19:25: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 TAA09685; Thu, 6 Sep 2001 19:20: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 TAA09652 for ; Thu, 6 Sep 2001 19:20:20 -0400 (EDT) Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11571 for ; Thu, 6 Sep 2001 19:18:54 -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 f86MUUW12982; Thu, 6 Sep 2001 15:30:34 -0700 Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Sep 2001 16:15:58 -0700 Message-ID: From: John LaCour To: "'Christian Huitema'" , midcom@ietf.org Subject: RE: [midcom] Topology considerations documents Date: Thu, 6 Sep 2001 16:18:11 -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 See comments below... > > +-------------+ > | | +------+ > | Customer A | | | +---------------+ > | +-----------+ | | | > | 10.0.0.x | | | | | > | | | | | Service | > +-------------+ |Middle| | Provider | > | Box +------+ | > +-------------+ | | | | > | | | | | 192.168.20.x | > | Customer B | | | | | > | +-----------+ | +---------------+ > | 10.0.0.x | | | > | | +------+ > +-------------+ > > Well, we may observe that such constructs are by and large > equivalent to > a multiple-box construct: > > +-------------+ > | | +------+ > | Customer A | | | +---------------+ > | +-----------+ MB-A | | | > | 10.0.0.x | | | | | > | | +......+ | Service | > +-------------+ . . | Provider | > . +------+ | > +-------------+ . . | | > | | +......+ | 192.168.20.x | > | Customer B | | | | | > | +-----------+ MB-B | +---------------+ > | 10.0.0.x | | | > | | +------+ > +-------------+ > > We don't want to split the hardware, but nothing prevents us from > adopting a logical view in which "MB-A" and "MB-B" are > different "midcom > servers", i.e. have different logical names. So, if an agent wants to > open a port for A, it sends comment to the midcom server > "MB-A", and to > "MB-B" if it wants to open a port for B. Pretty soon, we have > a generic > mechanism with a clear naming rule -- a name associated with the > protected domain -- and a simple semantic -- interior and exterior. > > Looks nice, uh? In total agreement. I just want a way in MIDCOM to specify MB-A or MB-B so that I can avoid having multiple MIDCOM servers on my middlebox and avoid duplicating authentication mechanisms whenever I have one middlebox agent talking to both MB-A and MB-B. -John _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 6 19:57:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12416 for ; Thu, 6 Sep 2001 19:57: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 TAA10611; Thu, 6 Sep 2001 19:42: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 TAA10580 for ; Thu, 6 Sep 2001 19:42:28 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11971 for ; Thu, 6 Sep 2001 19:41:02 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id SAA24551 for ; Thu, 6 Sep 2001 18:41:57 -0500 (CDT) Received: from zsc4c000.us.nortel.com by smtprch2.nortel.com; Thu, 6 Sep 2001 18:34:27 -0500 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Sep 2001 16:40:40 -0700 Message-ID: From: "Reinaldo Penno" To: "'John LaCour'" , "'Christian Huitema'" , "'midcom@ietf.org'" Subject: RE: [midcom] Topology considerations documents Date: Thu, 6 Sep 2001 16:40:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1372D.559D6940" 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_01C1372D.559D6940 Content-Type: text/plain; charset="iso-8859-1" Hello, I was going to write a draft about topologies, etc but IMO what those three drafts and recent comments (John, Mark, etc) are trying to get to is this: We need to go to http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-framework-01.txt and in every complex topology you see, substitute PE router by a MB and/or put a MB after or before the PE router. If we can then come up with a method identify each flow uniquely for all those cases, we are in good shape. regards, Reinaldo > -----Original Message----- > From: John LaCour [mailto:jlacour@netscreen.com] > Sent: Thursday, September 06, 2001 4:18 PM > To: 'Christian Huitema'; midcom@ietf.org > Subject: RE: [midcom] Topology considerations documents > > > See comments below... > > > > > > +-------------+ > > | | +------+ > > | Customer A | | | +---------------+ > > | +-----------+ | | | > > | 10.0.0.x | | | | | > > | | | | | Service | > > +-------------+ |Middle| | Provider | > > | Box +------+ | > > +-------------+ | | | | > > | | | | | 192.168.20.x | > > | Customer B | | | | | > > | +-----------+ | +---------------+ > > | 10.0.0.x | | | > > | | +------+ > > +-------------+ > > > > Well, we may observe that such constructs are by and large > > equivalent to > > a multiple-box construct: > > > > +-------------+ > > | | +------+ > > | Customer A | | | +---------------+ > > | +-----------+ MB-A | | | > > | 10.0.0.x | | | | | > > | | +......+ | Service | > > +-------------+ . . | Provider | > > . +------+ | > > +-------------+ . . | | > > | | +......+ | 192.168.20.x | > > | Customer B | | | | | > > | +-----------+ MB-B | +---------------+ > > | 10.0.0.x | | | > > | | +------+ > > +-------------+ > > > > We don't want to split the hardware, but nothing prevents us from > > adopting a logical view in which "MB-A" and "MB-B" are > > different "midcom > > servers", i.e. have different logical names. So, if an > agent wants to > > open a port for A, it sends comment to the midcom server > > "MB-A", and to > > "MB-B" if it wants to open a port for B. Pretty soon, we have > > a generic > > mechanism with a clear naming rule -- a name associated with the > > protected domain -- and a simple semantic -- interior and exterior. > > > > Looks nice, uh? > > > In total agreement. > > I just want a way in MIDCOM to specify MB-A or MB-B so that I can > avoid having multiple MIDCOM servers on my middlebox and > avoid duplicating > authentication mechanisms whenever I have one middlebox agent talking > to both MB-A and MB-B. > > -John > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C1372D.559D6940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Topology considerations documents

Hello,

I was going to write a draft about topologies, etc = but IMO what those three drafts and recent comments (John, Mark, etc) = are trying to get to is this:

We need to go to http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-f= ramework-01.txt and in every complex topology you see, substitute = PE router by a MB and/or put a MB after or before the PE router. If we = can then come up with a method identify each flow uniquely for all = those cases, we are in good shape.

regards,

Reinaldo



> -----Original Message-----
> From: John LaCour [mailto:jlacour@netscreen.com]<= /FONT>
> Sent: Thursday, September 06, 2001 4:18 = PM
> To: 'Christian Huitema'; midcom@ietf.org
> Subject: RE: [midcom] Topology considerations = documents
>
>
> See comments below...
>
> 
> >
> = >         +-------------+ =
> = >         = |            = ; |           = +------+
> = >         | Customer A  = |           = |      |      = +---------------+
> = >         = |            = ; +-----------+      = |      = |            = ;   |
> = >         |  = 10.0.0.x   = |           = |      |      = |            = ;   |
> = >         = |            = ; |           = |      |      = |   Service     |
> = >         = +-------------+         &nb= sp; |Middle|      |   = Provider    |
> = >           &n= bsp;           &n= bsp;           = |  Box = +------+          &nbs= p;    |
> >       &n= bsp; = +-------------+         &nb= sp; |      |      = |            = ;   |
> = >         = |            = ; |           = |      |      |  = 192.168.20.x |
> = >         | Customer B  = |           = |      |      = |            = ;   |
> = >         = |            = ; +-----------+      = |      +---------------+
> = >         |  = 10.0.0.x   = |           = |      |
> = >         = |            = ; |           = +------+
> = >         = +-------------+
> >
> > Well, we may observe that such constructs = are by and large
> > equivalent to
> > a multiple-box construct:
> >
> = >         +-------------+ =
> = >         = |            = ; |           = +------+
> = >         | Customer A  = |           = |      |      = +---------------+
> = >         = |            = ; +-----------+ MB-A |      = |            = ;   |
> = >         |  = 10.0.0.x   = |           = |      |      = |            = ;   |
> = >         = |            = ; |           = +......+      |   = Service     |
> = >         = +-------------+         &nb= sp; .      .      = |   Provider    |
> = >           &n= bsp;           &n= bsp;           = .      +------+     &= nbsp;         |
> = >         = +-------------+         &nb= sp; .      .      = |            = ;   |
> = >         = |            = ; |           = +......+      |  192.168.20.x |
> = >         | Customer B  = |           = |      |      = |            = ;   |
> = >         = |            = ; +-----------+ MB-B |      +---------------+ =
> = >         |  = 10.0.0.x   = |           = |      |
> = >         = |            = ; |           = +------+
> = >         = +-------------+
> >
> > We don't want to split the hardware, but = nothing prevents us from
> > adopting a logical view in which = "MB-A" and "MB-B" are
> > different "midcom
> > servers", i.e. have different logical = names. So, if an
> agent wants to
> > open a port for A, it sends comment to the = midcom server
> > "MB-A", and to
> > "MB-B" if it wants to open a = port for B. Pretty soon, we have
> > a generic
> > mechanism with a clear naming rule -- a = name associated with the
> > protected domain -- and a simple semantic = -- interior and exterior.
> >
> > Looks nice, uh?
>
>
> In total agreement.
>
> I just want a way in MIDCOM to specify MB-A or = MB-B so that I can
> avoid having multiple MIDCOM servers on my = middlebox and
> avoid duplicating
> authentication mechanisms whenever I have one = middlebox agent talking
> to both MB-A and MB-B.
>
> -John
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C1372D.559D6940-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 09:30:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12601 for ; Fri, 7 Sep 2001 09:30: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 JAA09973; Fri, 7 Sep 2001 09:29: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 JAA09893 for ; Fri, 7 Sep 2001 09:29:31 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12457 for ; Fri, 7 Sep 2001 09:28:05 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id ABBB109300AA; Fri, 07 Sep 2001 09:29:31 -0400 Message-ID: <00c501c137a0$f1f5d700$2300000a@acmepacket.com> From: "Bob Penfield" To: "Christian Huitema" , References: Subject: Re: [midcom] Topology considerations documents Date: Fri, 7 Sep 2001 09:28:12 -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: "Christian Huitema" To: Sent: Thursday, September 06, 2001 7:03 PM Subject: RE: [midcom] Topology considerations documents > I have read all three drafts, and have these feelings that we are well > on our way to define a camel... I would like a different analysis, > starting with the simplest topology and extending to the more complex > topologies envisaged in the draft. > > I guess we all agree that the simplest topology is that of the "basic > firewall" configuration: a protected domain that we can call "the > interior", and by opposition a non protected side that we can call "the > exterior". The concept of interior and exterior leads us in this case to > a very simple pinhole specification. The pinhole is identified by: > Interior address > Protocol type > Interior port > Exterior address > Exterior port > Indeed, each of these values can be wildcarded, or maybe replaced by a > "prefix" in the case of addresses. The pinhole will then have > attributes, such as: > Direction: send, recv, sendrecv, closed > Mapping of the interior address to the outside, if NAT > Maybe mapping of the exterior address on the inside > Etc. > A very good outcome of the directionality, i.e. from the inside out, is > that we can order the list of pinholes, as if the 5 tuple was one big > number. This allows us to define unambiguously which pinhole is most > specifically matching a given packet header -- i.e., in the matching > list, the one that comes first in the ordering, assuming that wildcards > rank after specified values. > > OK, so we have a cool simple solution for the simple case, so what about > the complex case, for example the case quoted in > draft-penfield-midcom-realms-00.txt in which a single box protects > several networks: > > > +-------------+ > | | +------+ > | Customer A | | | +---------------+ > | +-----------+ | | | > | 10.0.0.x | | | | | > | | | | | Service | > +-------------+ |Middle| | Provider | > | Box +------+ | > +-------------+ | | | | > | | | | | 192.168.20.x | > | Customer B | | | | | > | +-----------+ | +---------------+ > | 10.0.0.x | | | > | | +------+ > +-------------+ > > Well, we may observe that such constructs are by and large equivalent to > a multiple-box construct: > > +-------------+ > | | +------+ > | Customer A | | | +---------------+ > | +-----------+ MB-A | | | > | 10.0.0.x | | | | | > | | +......+ | Service | > +-------------+ . . | Provider | > . +------+ | > +-------------+ . . | | > | | +......+ | 192.168.20.x | > | Customer B | | | | | > | +-----------+ MB-B | +---------------+ > | 10.0.0.x | | | > | | +------+ > +-------------+ > > We don't want to split the hardware, but nothing prevents us from > adopting a logical view in which "MB-A" and "MB-B" are different "midcom > servers", i.e. have different logical names. So, if an agent wants to > open a port for A, it sends comment to the midcom server "MB-A", and to > "MB-B" if it wants to open a port for B. Pretty soon, we have a generic > mechanism with a clear naming rule -- a name associated with the > protected domain -- and a simple semantic -- interior and exterior. > > Looks nice, uh? This may be an over simplification. What happens when the flow needs to go from A to B? How does the midcom agent in SP create a single ruleset/pinhole/whatever to do that? A middlebox is multi-sided. In the simplest case it has two sides. But in this case it has 3 and it MUST be able to handle flows between any of the 3 sides. (-:bob _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 09:34: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 ESMTP id JAA12823 for ; Fri, 7 Sep 2001 09:34: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 JAA10314; Fri, 7 Sep 2001 09:31:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10286 for ; Fri, 7 Sep 2001 09:31:41 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12577 for ; Fri, 7 Sep 2001 09:30:14 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AC3D98013C; Fri, 07 Sep 2001 09:31:41 -0400 Message-ID: <00cb01c137a1$3f417000$2300000a@acmepacket.com> From: "Bob Penfield" To: "John LaCour" , "'Christian Huitema'" , References: Subject: Re: [midcom] Topology considerations documents Date: Fri, 7 Sep 2001 09:30:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.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: "John LaCour" To: "'Christian Huitema'" ; Sent: Thursday, September 06, 2001 7:18 PM Subject: RE: [midcom] Topology considerations documents > See comments below... > > > > > > +-------------+ > > | | +------+ > > | Customer A | | | +---------------+ > > | +-----------+ | | | > > | 10.0.0.x | | | | | > > | | | | | Service | > > +-------------+ |Middle| | Provider | > > | Box +------+ | > > +-------------+ | | | | > > | | | | | 192.168.20.x | > > | Customer B | | | | | > > | +-----------+ | +---------------+ > > | 10.0.0.x | | | > > | | +------+ > > +-------------+ > > > > Well, we may observe that such constructs are by and large > > equivalent to > > a multiple-box construct: > > > > +-------------+ > > | | +------+ > > | Customer A | | | +---------------+ > > | +-----------+ MB-A | | | > > | 10.0.0.x | | | | | > > | | +......+ | Service | > > +-------------+ . . | Provider | > > . +------+ | > > +-------------+ . . | | > > | | +......+ | 192.168.20.x | > > | Customer B | | | | | > > | +-----------+ MB-B | +---------------+ > > | 10.0.0.x | | | > > | | +------+ > > +-------------+ > > > > We don't want to split the hardware, but nothing prevents us from > > adopting a logical view in which "MB-A" and "MB-B" are > > different "midcom > > servers", i.e. have different logical names. So, if an agent wants to > > open a port for A, it sends comment to the midcom server > > "MB-A", and to > > "MB-B" if it wants to open a port for B. Pretty soon, we have > > a generic > > mechanism with a clear naming rule -- a name associated with the > > protected domain -- and a simple semantic -- interior and exterior. > > > > Looks nice, uh? > > > In total agreement. > > I just want a way in MIDCOM to specify MB-A or MB-B so that I can > avoid having multiple MIDCOM servers on my middlebox and avoid duplicating > authentication mechanisms whenever I have one middlebox agent talking > to both MB-A and MB-B. > This sounds very similar to an interface or realm identifier in the protocol. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 09:41: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 ESMTP id JAA13205 for ; Fri, 7 Sep 2001 09:41: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 JAA10607; Fri, 7 Sep 2001 09:41: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 JAA10576 for ; Fri, 7 Sep 2001 09:41:56 -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 ESMTP id JAA13092 for ; Fri, 7 Sep 2001 09:40:29 -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 JAA27418; Fri, 7 Sep 2001 09:41:55 -0400 (EDT) Message-Id: <200109071341.JAA27418@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Andrew Molitor cc: midcom@ietf.org Subject: Re: [midcom] Topology considerations documents In-reply-to: Your message of "Thu, 06 Sep 2001 15:39:52 CDT." Date: Fri, 07 Sep 2001 09:41:55 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > It is, in my opinion, ludicrous to propose that a middlebox > should possess anything resembling global knowledge. It is, in my opinion, ludicrous to propose that you can fix the problems with NATs without creating a global name space with a unique name for each realm This doesn't mean that the NAT needs to have anything like global knowledge, just that it knows the names of each of the address realms to which it connects. Keith p.s. the term "middlebox" is confusing here since it's only those middleboxes that do NAT that are causing this problem. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 09:50:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13713 for ; Fri, 7 Sep 2001 09: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 JAA10746; Fri, 7 Sep 2001 09:45: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 JAA10719 for ; Fri, 7 Sep 2001 09:45:07 -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 ESMTP id JAA13285 for ; Fri, 7 Sep 2001 09:43:40 -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 JAA27436; Fri, 7 Sep 2001 09:44:58 -0400 (EDT) Message-Id: <200109071344.JAA27436@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Duffy cc: "Bob Penfield" , "Scott Brim" , midcom@ietf.org Subject: Re: [midcom] Topology considerations documents In-reply-to: Your message of "Thu, 06 Sep 2001 17:16:50 EDT." <3.0.5.32.20010906171650.00a1d860@email.quarrytech.com> Date: Fri, 07 Sep 2001 09:44:58 -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 > My understanding is similar to what Bob has stated. The realm identifiers > only need to be unique within the middlebox that the midcom request is > directed to. True. But since you cannot anticipate the names of each of the realms to which you might someday want to connect, it seems wise to design a naming scheme which avoids conflicts. Global assignment is one way to do this; generating random names from a large name space is another. Keith p.s. I'm tempted to suggest that realm names should be IPv6 prefixes. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 09:59:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14088 for ; Fri, 7 Sep 2001 09:59: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 JAA11094; Fri, 7 Sep 2001 09:58: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 JAA11063 for ; Fri, 7 Sep 2001 09:58:47 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14009 for ; Fri, 7 Sep 2001 09:57:20 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q131AQ73; Fri, 7 Sep 2001 09:58:11 -0400 Message-Id: <3.0.5.32.20010907095300.009e2100@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 07 Sep 2001 09:53:00 -0400 To: Andrew Molitor , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Topology considerations documents In-Reply-To: References: <3.0.5.32.20010906182901.009cd100@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi Andrew, see below... At 05:43 PM 9/6/01 -0500, Andrew Molitor wrote: > > >On Thu, 6 Sep 2001, Mark Duffy wrote: > >> At 05:04 PM 9/6/01 -0500, Andrew Molitor wrote: >> > If you REALLY want to use realm names instead of interface >> >names in MIDCOM messages, please provide a real, useful example >> >where this would be >> > >> > a) useful >> > b) not isomorphic to interface names >> > >> > Andrew >> >> Picture a carrier-based middlebox that can provide a firewall service >> independently to multiple enterprises. Assume that it is possible that >> multiple enterprises A, B, and C may be connected to this middlebox *via >> the same interface* of the middlebox. A certain pinhole is to be opened >> for packets being sent to enterprise A, but not for those forwarded to B or >> C. To control this via midcom, "interface" is not a powerful enough >> criterion. "Realm", which is more general, is. >> >> > a) useful >> Yes, since it allows midcom to control this firewall >> >> > b) not isomorphic to interface names >> Yes, because in this case realm::interface is many::one > > What an excellent example! > > How would a middlebox identify the source and target realms >of a specific packet? I can think of some schemes using IP addresses >or the various and sundry Tags which can be shoved in packets. I >am happy to stipulate that this is a middlebox specific problem, >and we may assume that every packet is Somehow classified, and >has a Source Realm and a Target Realm attached to it before policy >is applied. Agreed that how the middlebox idientifies the source and target realms (and hence which policy to apply) for each packet is a MB issue, out of the scope of midcom. > One COULD make the case that this is just a fancied-up >interface, but I think it's fair to abstract it and call it something >else. I'm not sure whether to interpret the above as agreement that the midcom protocol should support specifying to the mb the more general concept of realm rather than only that of interface? > I tend to think of realms as bigger, less local objects. >E.G. > > > Realm A -middlebox-+ > | > [ big network ]-- middlebox --[ big network ]-- Many Realms > | > Realm B -middlebox-+ > > In this case, the middlebox in the center doesn't care >about Realm A versus Realm B, though an Agent trying to manage all >the middleboxes for a SIP call might. Your picture seems completely valid to me, but here is another picture: Enterprise A --- |--- middlebox ---- Internet Enterprise B --- . In this picture the middlebox is serving multiple realms, A and B. . Assume that the middlebox is also a router. . A and B may be using overlapping private addresses. . A and B must have separate security policies, NAT bindings, pinholes, etc. . Agent sending midcom commands to the mb with only the 5-tuple as the classifier criteria is insufficient -- it also needs to specify whether each rule is to be applied for A or for B. . If the middlebox/router uses one logical IP interface to connect to A and another to connect to B, then "ip interface" IS sufficient to qualify which realm a particular midcom command applies to. . HOWEVER, if the middlebox/router discerns A and B at some other granularity than the ip interface via which they are attached, a more general specification of realm is needed. Examples of different granularities at which a mb might distinguish its attached realms: - everything reached via some set of multiple ip interfaces - everything reached via a specific next hop router - everything reached via a specific physical port, regardless of logical interface - etc. > The middlebox in the center only cares about "Realm Everything >to the Left" and "Realm Everything to the Right" and THESE are the >indications that need to get sent to it over MIDCOM. These are >also the "Realm" names that get attached to packets as they >pass through that middlebox. True. I think the question at hand though is what constitutes a realm from the perspective of a generalized middlebox, and how do we specify realms in the midcom protocol in a way that is generic enough. > Would it be just too awful to use phrase "Global Realm" and >"Local Realm" where this distinction is needed? Not too awful at all, but in some cases of course the middlebox is connected to more than 2 realms. I think we have already agreed that we need to support that. > > Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 10:04:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14381 for ; Fri, 7 Sep 2001 10:04: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 KAA11485; Fri, 7 Sep 2001 10:03: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 KAA11455 for ; Fri, 7 Sep 2001 10:03:52 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14309 for ; Fri, 7 Sep 2001 10:02:25 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A3C522D70132; Fri, 07 Sep 2001 10:03:49 -0400 Message-ID: <00ef01c137a5$bc3b02c0$2300000a@acmepacket.com> From: "Bob Penfield" To: "midcom mail-list" Subject: Re: [midcom] Topology considerations documents Date: Fri, 7 Sep 2001 10:02:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.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 OK, let's try an example. +---------+ MB | Realm A +---\ +---+ +----------+ +---------+ +---+ VLAN1 | (2)----+ | |L2X+========(1) | WAN | Realm SP | +---------+ +---+ VLAN2 | (3)----+ | | Realm B +---/ +---+ +----------+ +---------+ Here's a middlebox connected to 3 networks (realms). It has 3 physical interface (1), (2), and (3). Realms A and B are connected to a Layer 2 switch (L2X) which aggregates/multiplexes the 2 LANs over a single ethernet connection to (1) using VLAN tags. Interfaces (2) and (3) both connect to the SP network for redundancy. There are 3 "logical" interfaces: VLAN1 and VLAN2 on physical interface (1) and WAN on physical interfaces (2)&(3). These logical interfaces are equivalent to the realm they connect to. The realm is at the other end of the logical pipe. Thus VLAN1=Realm A, VLAN2=Realm B, and WAN=Realm SP. I basically agree with Andrew that what were are trying to communicate to the middlebox is which interfaces the flow goes in/out of the middlebox. What I'm trying to illustrate above is that it is not physical interface, but logical interface that needs to be communicated in MIDCOM. Now if we want to call this logical interface (or even interface for short), that's fine with me. The middlebox owns the namespace for these logical interfaces. There is no need for a global or universal namespace. Only the midcom agents that talk to the middlebox need to be aware of the names/identifiers to use. Agents that need to differentiate the identifiers of multiple middleboxes COULD use the IP address or FQDN of the middlebox. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 10:30: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 ESMTP id KAA15523 for ; Fri, 7 Sep 2001 10:30: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 KAA12099; Fri, 7 Sep 2001 10:29: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 KAA12072 for ; Fri, 7 Sep 2001 10:29:38 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15399 for ; Fri, 7 Sep 2001 10:28:11 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q131AQ08; Fri, 7 Sep 2001 10:29:07 -0400 Message-Id: <3.0.5.32.20010907102800.007cd410@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 07 Sep 2001 10:28:00 -0400 To: "Christian Huitema" , From: Mark Duffy Subject: RE: [midcom] Topology considerations documents In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi Christian, I believe modelling the multi-realm middlebox as a number of logical 2-realm middleboxes as you suggest is sufficiently powerful and hence an acceptable alternative to specifying realms. I do take issue with one section of your posting: >I guess we all agree that the simplest topology is that of the "basic >firewall" configuration: a protected domain that we can call "the >interior", and by opposition a non protected side that we can call "the >exterior". The concept of interior and exterior leads us in this case to >a very simple pinhole specification. The pinhole is identified by: > Interior address > Protocol type > Interior port > Exterior address > Exterior port >Indeed, each of these values can be wildcarded, or maybe replaced by a >"prefix" in the case of addresses. The pinhole will then have >attributes, such as: > Direction: send, recv, sendrecv, closed > Mapping of the interior address to the outside, if NAT > Maybe mapping of the exterior address on the inside > Etc. >A very good outcome of the directionality, i.e. from the inside out, is >that we can order the list of pinholes, as if the 5 tuple was one big >number. This allows us to define unambiguously which pinhole is most >specifically matching a given packet header -- i.e., in the matching >list, the one that comes first in the ordering, assuming that wildcards >rank after specified values. I do not see how this affords a useful unambiguous way to determine the relative precedence of rules that may match a packet in the presence of wildcards. If we have Rule 1: SA= any, DA= 1.2.3.4, protocol= any, SP= any, DP= any Rule 2: SA= any, DA= any, protocol= tcp, SP= any, DP= any Then which rule does a tcp packet to address 1.2.3.4 match? Do you propose to concatenate the fields of the tuple in some fixed order eg SA|DA|P|SP|DP and also specify a lexicographic sorting order between 1 bits, 0 bits, and don't care bits? That would make the system deterministic but I'm not sure it would be meaningful/useful. How is one to decide which fields of the tuple are more "important" hence more significant in the concatenation? And, what about future extensibility if more fields are added to the n-tuple. Do they just go at the least significant end in the order they are defined? And systems that don't support particular optional n-tuple fields omit them? -Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 10:44: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 ESMTP id KAA16086 for ; Fri, 7 Sep 2001 10:44: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 KAA12671; Fri, 7 Sep 2001 10:39: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 KAA12642 for ; Fri, 7 Sep 2001 10:39: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 ESMTP id KAA15806 for ; Fri, 7 Sep 2001 10:38:09 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q131ARAS; Fri, 7 Sep 2001 10:39:05 -0400 Message-Id: <3.0.5.32.20010907103814.00852150@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 07 Sep 2001 10:38:14 -0400 To: Keith Moore From: Mark Duffy Subject: Re: [midcom] Topology considerations documents Cc: "Bob Penfield" , "Scott Brim" , midcom@ietf.org In-Reply-To: <200109071344.JAA27436@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 09:44 AM 9/7/01 -0400, Keith Moore wrote: >> My understanding is similar to what Bob has stated. The realm identifiers >> only need to be unique within the middlebox that the midcom request is >> directed to. > >True. But since you cannot anticipate the names of each of the realms >to which you might someday want to connect, it seems wise to design a >naming scheme which avoids conflicts. Global assignment is one way to >do this; generating random names from a large name space is another. > >Keith > >p.s. I'm tempted to suggest that realm names should be IPv6 prefixes. Keith, I do not see why naming conflicts should arise here. The realm identifiers we are speaking of here are sent by an agent to a specific middlebox. These realm identifiers are interpreted only by the middlebox to which they are sent. If we used interfaces rather than realms, the story would be the same: the interface names would only need to be unique within the particular middlebox to which they would be sent. One way of looking at this is that the realm names are in a sense qualified by the address/name/whatever of the middlebox (which address/name/whatever is presumably unique over a "sufficient" area). So the effective realm names are actually something like { ; Fri, 7 Sep 2001 10:45:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12850; Fri, 7 Sep 2001 10:44: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 KAA12821 for ; Fri, 7 Sep 2001 10:44:45 -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 ESMTP id KAA15994 for ; Fri, 7 Sep 2001 10:43:18 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id 2E77A825D for ; Fri, 7 Sep 2001 09:44:37 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id JAA05086 for ; Fri, 7 Sep 2001 09:44:36 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Fri, 7 Sep 2001 09:44:35 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Topology considerations documents In-Reply-To: <3.0.5.32.20010907095300.009e2100@email.quarrytech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Fri, 7 Sep 2001, Mark Duffy wrote: > At 05:43 PM 9/6/01 -0500, Andrew Molitor wrote: > > One COULD make the case that this is just a fancied-up > >interface, but I think it's fair to abstract it and call it something > >else. > > I'm not sure whether to interpret the above as agreement that the midcom > protocol should support specifying to the mb the more general concept of > realm rather than only that of interface? I agree, I am just unsure of what to NAME the more general thing! > > > Would it be just too awful to use phrase "Global Realm" and > >"Local Realm" where this distinction is needed? > > Not too awful at all, but in some cases of course the middlebox is > connected to more than 2 realms. I think we have already agreed that we > need to support that. Oh, absolutely. The point is that, to my way of thinking, a particular middlebox "sees" potentially fewer realms than an Agent does. MIDCOM communications need to be in terms of the ones the middlebox sees, since the middlebox is the Dumb End of the protocol. The stuff that appears in MIDCOM messages should therefore be "Local Realms" Agent _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 10:46: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 ESMTP id KAA16184 for ; Fri, 7 Sep 2001 10:46:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12910; Fri, 7 Sep 2001 10:46: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 KAA12880 for ; Fri, 7 Sep 2001 10:46:12 -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 ESMTP id KAA16067 for ; Fri, 7 Sep 2001 10:44:44 -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 KAA28084; Fri, 7 Sep 2001 10:46:08 -0400 (EDT) Message-Id: <200109071446.KAA28084@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Duffy cc: Keith Moore , "Bob Penfield" , "Scott Brim" , midcom@ietf.org Subject: Re: [midcom] Topology considerations documents In-reply-to: Your message of "Fri, 07 Sep 2001 10:38:14 EDT." <3.0.5.32.20010907103814.00852150@email.quarrytech.com> Date: Fri, 07 Sep 2001 10:46:08 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > Keith, I do not see why naming conflicts should arise here. The realm > identifiers we are speaking of here are sent by an agent to a specific > middlebox. These realm identifiers are interpreted only by the middlebox > to which they are sent. they're shared among the NATs and the agents. there may be multiple NATs and multiple agents that need to know about the realm names. > If we used interfaces rather than realms, the > story would be the same: the interface names would only need to be unique > within the particular middlebox to which they would be sent. interface names are slightly less general, particularly across equipment changes. > One way of looking at this is that the realm names are in a sense qualified > by the address/name/whatever of the middlebox (which address/name/whatever > is presumably unique over a "sufficient" area). So the effective realm > names are actually something like > { ; Fri, 7 Sep 2001 11:43: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 LAA14689; Fri, 7 Sep 2001 11:39: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 LAA14659 for ; Fri, 7 Sep 2001 11:39:16 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17438 for ; Fri, 7 Sep 2001 11:37:48 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AA2056090130; Fri, 07 Sep 2001 11:39:12 -0400 Message-ID: <004c01c137b3$0e97fd40$2300000a@acmepacket.com> From: "Bob Penfield" To: "Keith Moore" , "Mark Duffy" Cc: "Scott Brim" , References: <200109071446.KAA28084@astro.cs.utk.edu> Subject: Re: [midcom] Topology considerations documents Date: Fri, 7 Sep 2001 11:37:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Keith Moore" To: "Mark Duffy" Cc: "Keith Moore" ; "Bob Penfield" ; "Scott Brim" ; Sent: Friday, September 07, 2001 10:46 AM Subject: Re: [midcom] Topology considerations documents > > Keith, I do not see why naming conflicts should arise here. The realm > > identifiers we are speaking of here are sent by an agent to a specific > > middlebox. These realm identifiers are interpreted only by the middlebox > > to which they are sent. > > they're shared among the NATs and the agents. there may be multiple NATs > and multiple agents that need to know about the realm names. > > > If we used interfaces rather than realms, the > > story would be the same: the interface names would only need to be unique > > within the particular middlebox to which they would be sent. > > interface names are slightly less general, particularly across equipment > changes. > > > One way of looking at this is that the realm names are in a sense qualified > > by the address/name/whatever of the middlebox (which address/name/whatever > > is presumably unique over a "sufficient" area). So the effective realm > > names are actually something like > > { > it's not safe to assume that the NAT has a unique IP address, even > within the set of realms which are of interest. If that NAT middlebox can talk MIDCOM, I would think it has to have an IP address for the MIDCOM agent to send messages to. > Keith > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 11:57: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 ESMTP id LAA18068 for ; Fri, 7 Sep 2001 11:57: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 LAA15204; Fri, 7 Sep 2001 11:51: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 LAA15177 for ; Fri, 7 Sep 2001 11:51:07 -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 ESMTP id LAA17772 for ; Fri, 7 Sep 2001 11:49: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 11BBB81B9 for ; Fri, 7 Sep 2001 10:50:59 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id KAA08797 for ; Fri, 7 Sep 2001 10:50:58 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Fri, 7 Sep 2001 10:50:58 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: Re: [midcom] Topology considerations documents In-Reply-To: <200109071446.KAA28084@astro.cs.utk.edu> 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 None of what I am about to say is MIDCOM related, for which I apologize in advance. I think the idea of globally naming Global Realms is a great idea. It's also completely out of scope for MIDCOM, and I don't think it's at all necessary for MIDCOM, which can treat Realms as not much more than a cookie that the Agent and middlebox agree on. If we stipulate that: 1) IPv4 has scaling problems at a certain point. 2) An approach to dealing with this would be to devise a way to interconnect IPv4 networks at a higher layer, just as Ethernets are interconnected using IPv4 Then we can rename NATs "Inter-Realm Routers" and achieve great happiness. Given Realms and a global naming scheme for them, together with a) a discovery/mapping service, probably a little like DNS but carting around realm naming and "coarse topology" information. b) a protocol like MIDCOM for setting up end-to-end paths by adding net-to-net bindings (i.e. NAT Bindings) to Inter-Realm Routers (i.e. middleboxes) we can back into a sort of disney version of Noel Chiappa's nimrod work that has the advantage of being built ON IPv4 instead of replacing it, which is wicked cool. Nimrod-like solutions have much nicer scaling properties than IPv4-like solutions like, say, IPv6 (which is arguably no more scalable than IPv4 -- just BIGGER). I'm so glad to see that Keith is finally on board the whole NAT, err, Inter-Realm Router, thing! Andrew _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 12:00:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18223 for ; Fri, 7 Sep 2001 12:00:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15618; Fri, 7 Sep 2001 11:59: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 LAA15591 for ; Fri, 7 Sep 2001 11:59:34 -0400 (EDT) Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18100 for ; Fri, 7 Sep 2001 11:58:01 -0400 (EDT) Received: from 157.54.9.108 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Sep 2001 08:58:46 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Sep 2001 08:58:46 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Sep 2001 08:58:45 -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, 7 Sep 2001 08:58:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 7 Sep 2001 08:58:14 -0700 Message-ID: Thread-Topic: Precedence of wildcards Thread-Index: AcE3qWaBo+hmTGyARIq32rT1hmQ+nQACz6ng From: "Christian Huitema" To: "Mark Duffy" , X-OriginalArrivalTime: 07 Sep 2001 15:58:15.0058 (UTC) FILETIME=[E7331F20:01C137B5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA15592 Subject: [midcom] Precedence of wildcards Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > I do not see how this affords a useful unambiguous way to determine > the > relative precedence of rules that may match a packet in the presence > of > wildcards. > > If we have > Rule 1: SA= any, DA= 1.2.3.4, protocol= any, SP= any, DP= any > Rule 2: SA= any, DA= any, protocol= tcp, SP= any, DP= any > Then which rule does a tcp packet to address 1.2.3.4 match? Note that my proposal is not to use "source address" and "destination address", but "interior address" and "exterior address", precisely because it is a better match to practical filters -- you are much more likely to allow every external host to communicate with an interior server than the other way around. The order I propose was: > Interior address > Protocol type > Interior port > Exterior address > Exterior port Assuming that the rules are: Rule 1: IA= any, protocol= any, IP= any, EA= 1.2.3.4, EP= any Rule 2: IA= any, protocol= tcp, IP= any, EA= any, EP= any Then rule 2 takes precedence. This may not be what you wish, but it is unambiguous and predictable. It means that if you want to override rule 2, you will have to enter an extra rule: Rule 2: IA= any, protocol= tcp, IP= any, EA= 1.2.3.4, EP= any Indeed, we could decide to decide that address values should take precedence over protocol type, and change the ordering to: Interior address Exterior address Protocol type Interior port Exterior port In this case, rule 1 would take precedence. The basic point is that the protocol should pick a very specific ordering, so that there is no ambiguity. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 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 ESMTP id MAA18237 for ; Fri, 7 Sep 2001 12:00:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15448; Fri, 7 Sep 2001 11:56:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15418 for ; Fri, 7 Sep 2001 11:56: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 ESMTP id LAA18036 for ; Fri, 7 Sep 2001 11:55:23 -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 LAA01586; Fri, 7 Sep 2001 11:56:48 -0400 (EDT) Message-Id: <200109071556.LAA01586@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bob Penfield" cc: "Keith Moore" , "Mark Duffy" , "Scott Brim" , midcom@ietf.org Subject: Re: [midcom] Topology considerations documents In-reply-to: Your message of "Fri, 07 Sep 2001 11:37:52 EDT." <004c01c137b3$0e97fd40$2300000a@acmepacket.com> Date: Fri, 07 Sep 2001 11:56:48 -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 > > it's not safe to assume that the NAT has a unique IP address, even > > within the set of realms which are of interest. > > If that NAT middlebox can talk MIDCOM, I would think it has to have an IP > address for the MIDCOM agent to send messages to. yes, of course. but to restate - that IP address might not be globally unique, and the same IP address may well be reused within the set of realms which are of interest. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 12:05:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18505 for ; Fri, 7 Sep 2001 12:05: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 MAA16749; Fri, 7 Sep 2001 12:05: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 MAA16720 for ; Fri, 7 Sep 2001 12:05:23 -0400 (EDT) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18424 for ; Fri, 7 Sep 2001 12:03:52 -0400 (EDT) Received: from 157.54.7.67 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Sep 2001 09:04:24 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Sep 2001 09:04:23 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Sep 2001 09:04:05 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Sep 2001 09:03:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Topology considerations documents Date: Fri, 7 Sep 2001 09:03:33 -0700 Message-ID: Thread-Topic: [midcom] Topology considerations documents Thread-Index: AcE3tlF3xjT5OYZ9QO6rLpRgrNqvFQAAF28w From: "Christian Huitema" To: "Andrew Molitor" , X-OriginalArrivalTime: 07 Sep 2001 16:03:34.0565 (UTC) FILETIME=[A5A40550:01C137B6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA16721 Sender: 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 We have an inter-realm solution: IPv6. > -----Original Message----- > From: Andrew Molitor [mailto:amolitor@visi.com] > Sent: Friday, September 07, 2001 8:51 AM > To: midcom@ietf.org > Subject: Re: [midcom] Topology considerations documents > > None of what I am about to say is MIDCOM related, for which I > apologize in advance. > > I think the idea of globally naming Global Realms is a great > idea. It's also completely out of scope for MIDCOM, and I don't think > it's at all necessary for MIDCOM, which can treat Realms as not > much more than a cookie that the Agent and middlebox agree on. > > If we stipulate that: > > 1) IPv4 has scaling problems at a certain point. > 2) An approach to dealing with this would be to devise a > way to interconnect IPv4 networks at a higher layer, > just as Ethernets are interconnected using IPv4 > > Then we can rename NATs "Inter-Realm Routers" and achieve > great happiness. > > Given Realms and a global naming scheme for them, together with > > a) a discovery/mapping service, probably a little like DNS > but carting around realm naming and "coarse topology" > information. > b) a protocol like MIDCOM for setting up end-to-end paths > by adding net-to-net bindings (i.e. NAT Bindings) to > Inter-Realm Routers (i.e. middleboxes) > > we can back into a sort of disney version of Noel Chiappa's > nimrod work that has the advantage of being built ON IPv4 instead > of replacing it, which is wicked cool. > > Nimrod-like solutions have much nicer scaling properties than > IPv4-like solutions like, say, IPv6 (which is arguably no more > scalable > than IPv4 -- just BIGGER). > > I'm so glad to see that Keith is finally on board the whole > NAT, err, Inter-Realm Router, thing! > > Andrew > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 12:17:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18795 for ; Fri, 7 Sep 2001 12:17: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 MAA16936; Fri, 7 Sep 2001 12:12: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 MAA16909 for ; Fri, 7 Sep 2001 12:12:21 -0400 (EDT) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18668 for ; Fri, 7 Sep 2001 12:10:53 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id A10488107 for ; Fri, 7 Sep 2001 11:12:21 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id LAA10182 for ; Fri, 7 Sep 2001 11:12:21 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Fri, 7 Sep 2001 11:12:21 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] Topology considerations documents In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Fri, 7 Sep 2001, Christian Huitema wrote: > We have an inter-realm solution: IPv6. While I appreciate your desire to inform, I admit that I actually was aware of IPv6 already. The Inter-Realm Router is merely an alternative to it. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 12:29:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19306 for ; Fri, 7 Sep 2001 12:29: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 MAA17361; Fri, 7 Sep 2001 12:29: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 MAA17334 for ; Fri, 7 Sep 2001 12:29:33 -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 MAA19237 for ; Fri, 7 Sep 2001 12:28:04 -0400 (EDT) Message-ID: <20010907162932.66339.qmail@web13805.mail.yahoo.com> Received: from [65.12.33.187] by web13805.mail.yahoo.com via HTTP; Fri, 07 Sep 2001 09:29:32 PDT Date: Fri, 7 Sep 2001 09:29:32 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Terms needing definition or replacement To: Scott Brim , Melinda Shore Cc: midcom@ietf.org In-Reply-To: <20010905191558.A536@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: > On Wed, Sep 05, 2001 10:58:23AM -0400, Melinda Shore allegedly wrote: > > Ruleset > > A set of rules which are installed and removed as a unit. A combination > of a filtering (matching) specification and one or more action > specifications. How complex these can be is not defined. > > (This is the generic I prefer. It's specific, it's not ambiguous, and > it includes all the functions of all the others, e.g. pinhole). > Rules are middlebox function specific. Filters in the case of a firewall and address maps and BINDs in the case of NAT. > > Pinhole > > A ruleset where the main action specification is either to allow packets > to traverse the middlebox or to allow it through with address and/or > port translation. > > (If you want to keep using this word, I suggest separating out the two > different kinds of pinholes. "translated" versus "straight-through" > pinholes, maybe.) > A pinhole, in my mind, is simply a filtering rule - a specific tuple to be permitted or denied by a firewall. > > Connection > > Rewrite to eliminate all occurrences of this word. Don't assume any > state maintenance mechanism. > Agreed. I suggest replacing with "MIDCOM session" to be defined as follows. MIDCOM session is defined to be a lasting association between a MIDCOM agent and a middlebox. The MIDCOM session is not assumed to imply any specific transport layer protocol. Specifically, this should not be construed as refering to a connection-oriented TCP protocol. > > Pinhole-descriptor (the thing describing the state that's been > > created on the middlebox) > > Ruleset. > See my comment above. > > flow/resource > > Eliminate. > Are you saying, eliminate the definition of a middlebox resource (or) eliminate the discussion on middlebox resource? > > Melinda > > ..Scott > cheers, suresh ===== __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 13:06:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20668 for ; Fri, 7 Sep 2001 13:06: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 NAA18723; Fri, 7 Sep 2001 13:02: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 NAA18694 for ; Fri, 7 Sep 2001 13:02:36 -0400 (EDT) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20493 for ; Fri, 7 Sep 2001 13:01:06 -0400 (EDT) Received: from 157.54.1.52 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Sep 2001 10:00:53 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Sep 2001 10:00:55 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Sep 2001 10:00:52 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Sep 2001 10:00:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Topology considerations documents Date: Fri, 7 Sep 2001 10:00:21 -0700 Message-ID: Thread-Topic: [midcom] Topology considerations documents Thread-Index: AcE3uNUrCNxMrIQCRimjD8EzuY2nvwABClnw From: "Christian Huitema" To: "Andrew Molitor" , X-OriginalArrivalTime: 07 Sep 2001 17:00:22.0221 (UTC) FILETIME=[94C30FD0:01C137BE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA18695 Sender: 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 > > We have an inter-realm solution: IPv6. > > While I appreciate your desire to inform, I admit that I > actually > was aware of IPv6 already. The Inter-Realm Router is merely an > alternative to it. There is no such thing as an Inter-Realm Router in the Internet architecture; supporting such a beast is not a requirement of MIDCOM. To be very specific, I would contend that it is not possible today to build a single box connecting two domains A and B to the Internet, allocate the exact same address range to A and B, and allow direct communication between A and B. With the existing TCP-IP stacks, the only way for an A-host to speak to a B-host is to stick in the TCP-IP header an address that will be "natted" back to B. There is definitely no realm-identifier anywhere in the packet; mapping has to be based solely on the addresses and port numbers. What we do find today are either two layers of NAT: - NAT -+ - NAT -+ - FW -+- provider X: 10.x.x.x - NAT - Global Or "back to back" NAT configurations, such as: < domain A: 10.x.x.x > -- NAT --+ | Interconnect: 172.16.x.x < domain B: 10.x.x.x > -- NAT --+ -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 13:11: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 ESMTP id NAA20865 for ; Fri, 7 Sep 2001 13:11: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 NAA18871; Fri, 7 Sep 2001 13:06:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18840 for ; Fri, 7 Sep 2001 13:06: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 ESMTP id NAA20602 for ; Fri, 7 Sep 2001 13:05:25 -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 f87H6Kx23276 for ; Fri, 7 Sep 2001 10:06:20 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-176.cisco.com [10.21.96.176]) by airborne.cisco.com (Mirapoint) with SMTP id AAV03917; Fri, 7 Sep 2001 10:06:20 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Fri, 7 Sep 2001 13:06:20 -0400 Date: Fri, 7 Sep 2001 13:06:20 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Terms needing definition or replacement Message-ID: <20010907130619.E1308@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <20010905191558.A536@SBRIM-W2K> <20010907162932.66339.qmail@web13805.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: <20010907162932.66339.qmail@web13805.mail.yahoo.com>; from srisuresh@yahoo.com on Fri, Sep 07, 2001 at 09:29:32AM -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 Fri, Sep 07, 2001 09:29:32AM -0700, Pyda Srisuresh allegedly wrote: > > --- Scott Brim wrote: > > On Wed, Sep 05, 2001 10:58:23AM -0400, Melinda Shore allegedly wrote: > > > Ruleset > > > > A set of rules which are installed and removed as a unit. A combination > > of a filtering (matching) specification and one or more action > > specifications. How complex these can be is not defined. > > > > (This is the generic I prefer. It's specific, it's not ambiguous, and > > it includes all the functions of all the others, e.g. pinhole). > > > > Rules are middlebox function specific. Filters in the case of a firewall > and address maps and BINDs in the case of NAT. I think you're agreeing that "rule" is an appropriate generic term, but disagreeing on "filter". Tell me if that's not true. Would "matching" be better than "filtering"? > > > Pinhole > > > > A ruleset where the main action specification is either to allow packets > > to traverse the middlebox or to allow it through with address and/or > > port translation. > > > > (If you want to keep using this word, I suggest separating out the two > > different kinds of pinholes. "translated" versus "straight-through" > > pinholes, maybe.) > > > > A pinhole, in my mind, is simply a filtering rule - a specific tuple > to be permitted or denied by a firewall. Exactly. A pinhole is the reification of a rule. > > > > Connection > > > > Rewrite to eliminate all occurrences of this word. Don't assume any > > state maintenance mechanism. > > > Agreed. I suggest replacing with "MIDCOM session" to be defined > as follows. > > MIDCOM session is defined to be a lasting association between > a MIDCOM agent and a middlebox. The MIDCOM session is not > assumed to imply any specific transport layer protocol. > Specifically, this should not be construed as refering to a > connection-oriented TCP protocol. This looks good to me. With this definition we can keep 'session'. > > > > > Pinhole-descriptor (the thing describing the state that's been > > > created on the middlebox) > > > > Ruleset. > > > > See my comment above. and my response. I'm not sure if you're saying > > > > flow/resource > > > > Eliminate. > > > Are you saying, eliminate the definition of a middlebox resource > (or) eliminate the discussion on middlebox resource? Eliminate the use of the term. I believe the way "resource" has been used it's synonymous with "ruleset". That is, a bit of state which can be installed or removed through the midcom protocol. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 13:51:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21949 for ; Fri, 7 Sep 2001 13:51: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 NAA20235; Fri, 7 Sep 2001 13:46:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20206 for ; Fri, 7 Sep 2001 13:46:19 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21774 for ; Fri, 7 Sep 2001 13:44:52 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A7E7AF790130; Fri, 07 Sep 2001 13:46:15 -0400 Message-ID: <00cf01c137c4$ca6ddd80$2300000a@acmepacket.com> From: "Bob Penfield" To: "Christian Huitema" , "Andrew Molitor" , References: Subject: Re: [midcom] Topology considerations documents Date: Fri, 7 Sep 2001 13:44:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Christian Huitema" To: "Andrew Molitor" ; Sent: Friday, September 07, 2001 1:00 PM Subject: RE: [midcom] Topology considerations documents > > > We have an inter-realm solution: IPv6. > > > > While I appreciate your desire to inform, I admit that I > > actually > > was aware of IPv6 already. The Inter-Realm Router is merely an > > alternative to it. > > There is no such thing as an Inter-Realm Router in the Internet > architecture; supporting such a beast is not a requirement of MIDCOM. > > To be very specific, I would contend that it is not possible today to > build a single box connecting two domains A and B to the Internet, > allocate the exact same address range to A and B, and allow direct > communication between A and B. With the existing TCP-IP stacks, the only > way for an A-host to speak to a B-host is to stick in the TCP-IP header > an address that will be "natted" back to B. There is definitely no > realm-identifier anywhere in the packet; mapping has to be based solely > on the addresses and port numbers. My draft has a detailed example of how this is done. The private endpoints send to a public address which gets NATed to the private address in the other domain. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 14:20:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22870 for ; Fri, 7 Sep 2001 14:20: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 OAA21499; Fri, 7 Sep 2001 14:16: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 OAA21468 for ; Fri, 7 Sep 2001 14:16:52 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22696 for ; Fri, 7 Sep 2001 14:15: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 OAA02486; Fri, 7 Sep 2001 14:16:50 -0400 (EDT) Message-Id: <200109071816.OAA02486@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Andrew Molitor cc: midcom@ietf.org Subject: Re: [midcom] Topology considerations documents In-reply-to: Your message of "Fri, 07 Sep 2001 10:50:58 CDT." Date: Fri, 07 Sep 2001 14:16: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 > If we stipulate that: > > 1) IPv4 has scaling problems at a certain point. > 2) An approach to dealing with this would be to devise a > way to interconnect IPv4 networks at a higher layer, > just as Ethernets are interconnected using IPv4 > > Then we can rename NATs "Inter-Realm Routers" and achieve > great happiness. ah, no. either the resulting inter-network has a global address space (in which case you may as well punt midcom and use IPv6), or the resulting inter-network will be overly complex and brittle and only support a narrow range of applications. it may be that the latter network has better scaling properties. but what's the point of a scalable network that doesn't support apps, or that does so only by requiring apps to understand and explicitly deal with network topology? Keith p.s. I'm glad to see that midcom is realizing that a global address space is essential :) _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 14:37:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23559 for ; Fri, 7 Sep 2001 14:37: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 OAA22645; Fri, 7 Sep 2001 14:34: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 OAA22620 for ; Fri, 7 Sep 2001 14:34: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 ESMTP id OAA23366 for ; Fri, 7 Sep 2001 14:32:37 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q131ARWB; Fri, 7 Sep 2001 14:33:34 -0400 Message-Id: <3.0.5.32.20010907143245.00a1c170@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 07 Sep 2001 14:32:45 -0400 To: "Christian Huitema" , From: Mark Duffy In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Re: Precedence of wildcards Sender: 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:58 AM 9/7/01 -0700, Christian Huitema wrote: ... >Note that my proposal is not to use "source address" and "destination >address", but "interior address" and "exterior address", precisely >because it is a better match to practical filters -- you are much more >likely to allow every external host to communicate with an interior >server than the other way around. The order I propose was: > >> Interior address >> Protocol type >> Interior port >> Exterior address >> Exterior port OK, I understand your point is to use interior/exterior rather than source/dest. From your earlier post, you would then have an action associated with this rule such as { send, recv, sendrecv, closed } which controls which direction(s) packets are permitted to flow. However, I believe interior/exterior and source/dest are logically equivalent since a simple converion can produce one from the other: For packets received (from the Interior) Interior addr = source address and exterior addr = dest address. And for packets sent (to the Interior) Interior addr = dest address and exterior addr = source address. Therefore I don't understand *why* the interior/exterior view of things lends itself any better than the source/dest view to imposing a canonical ordering on widcarded rules. Could you explain that? Thanks, Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 14:58:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24773 for ; Fri, 7 Sep 2001 14:58: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 OAA23345; Fri, 7 Sep 2001 14:55: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 OAA23317 for ; Fri, 7 Sep 2001 14:55:58 -0400 (EDT) Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24551 for ; Fri, 7 Sep 2001 14:54:29 -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 f87I95W09722; Fri, 7 Sep 2001 11:09:06 -0700 Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 11:54:34 -0700 Message-ID: From: John LaCour To: "'Christian Huitema'" , Mark Duffy , midcom@ietf.org Subject: RE: [midcom] Precedence of wildcards Date: Fri, 7 Sep 2001 11:56:41 -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 I don't understand why we're talking about rule precedence. If a packet is allowed through under rule 1 or rule 2 the result is the same. Rule precedence is a middlebox implementation issue. I don't think there are any issues until MIDCOM is extended to include policy changes that say "block this kind of traffic". Even then I'll probably stay in the camp that its a middlebox implementation issue. -John > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Friday, September 07, 2001 8:58 AM > To: Mark Duffy; midcom@ietf.org > Subject: [midcom] Precedence of wildcards > > > > I do not see how this affords a useful unambiguous way to determine > > the > > relative precedence of rules that may match a packet in the presence > > of > > wildcards. > > > > If we have > > Rule 1: SA= any, DA= 1.2.3.4, protocol= any, SP= any, DP= any > > Rule 2: SA= any, DA= any, protocol= tcp, SP= any, DP= any > > Then which rule does a tcp packet to address 1.2.3.4 match? > > Note that my proposal is not to use "source address" and "destination > address", but "interior address" and "exterior address", precisely > because it is a better match to practical filters -- you are much more > likely to allow every external host to communicate with an interior > server than the other way around. The order I propose was: > > > Interior address > > Protocol type > > Interior port > > Exterior address > > Exterior port > > Assuming that the rules are: > > Rule 1: IA= any, protocol= any, IP= any, EA= 1.2.3.4, EP= any > Rule 2: IA= any, protocol= tcp, IP= any, EA= any, EP= any > > Then rule 2 takes precedence. This may not be what you wish, but it is > unambiguous and predictable. It means that if you want to > override rule > 2, you will have to enter an extra rule: > > Rule 2: IA= any, protocol= tcp, IP= any, EA= 1.2.3.4, EP= any > > Indeed, we could decide to decide that address values should take > precedence over protocol type, and change the ordering to: > > Interior address > Exterior address > Protocol type > Interior port > Exterior port > > In this case, rule 1 would take precedence. The basic point > is that the > protocol should pick a very specific ordering, so that there is no > ambiguity. > > -- Christian Huitema > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 15:26: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 ESMTP id PAA25518 for ; Fri, 7 Sep 2001 15:26: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 PAA24042; Fri, 7 Sep 2001 15:17: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 PAA24013 for ; Fri, 7 Sep 2001 15:17:32 -0400 (EDT) Received: from inet-vrs-02.redmond.corp.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25314 for ; Fri, 7 Sep 2001 15:16:03 -0400 (EDT) Received: from 157.54.7.67 by inet-vrs-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Sep 2001 12:15:51 -0700 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, 7 Sep 2001 12:15: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); Fri, 7 Sep 2001 12:15:51 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Sep 2001 12:15:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Precedence of wildcards Date: Fri, 7 Sep 2001 12:15:20 -0700 Message-ID: Thread-Topic: [midcom] Precedence of wildcards Thread-Index: AcE3zrzOLsdk7XCsTpmqqoGapjFqZwAAhdsQ From: "Christian Huitema" To: "John LaCour" , "Mark Duffy" , X-OriginalArrivalTime: 07 Sep 2001 19:15:20.0643 (UTC) FILETIME=[6FCC3130:01C137D1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA24014 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > I don't understand why we're talking about rule precedence. > If a packet is allowed through under rule 1 or rule 2 the > result is the same. Because rules have attributes. I may well have two overlapping rules, such as: Rule 1: ID: IA=*, EA=*, Proto=TCP, IPort = *, EPort = * Attribute: only authorize outgoing connections Rule 2: ID: IA=10.0.0.1, EA=*, Proto=TCP, IPort = 80, EPort = * Attribute: accept incoming connections. It matters greatly whether apply one or the other... > Rule precedence is a middlebox implementation issue. No it is not. We have agreed that it was a protocol requirement that the result be predictable and consistent in the presence of multiple rules. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 15:27:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25549 for ; Fri, 7 Sep 2001 15:27:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24249; Fri, 7 Sep 2001 15:24: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 PAA24222 for ; Fri, 7 Sep 2001 15:24:31 -0400 (EDT) Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25442 for ; Fri, 7 Sep 2001 15:23:02 -0400 (EDT) Received: from 157.54.9.108 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Sep 2001 12:23:52 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Sep 2001 12:23:51 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Sep 2001 12:23:50 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Sep 2001 12:23:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 7 Sep 2001 12:23:19 -0700 Message-ID: Thread-Topic: Precedence of wildcards Thread-Index: AcE3y7bQp9AoDcbOQ/io1NL+jVQVhwABdQNA From: "Christian Huitema" To: "Mark Duffy" , X-OriginalArrivalTime: 07 Sep 2001 19:23:20.0471 (UTC) FILETIME=[8DCC2270:01C137D2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA24223 Subject: [midcom] RE: Precedence of wildcards Sender: 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 > Therefore I don't understand *why* the interior/exterior view of > things lends itself any better than the source/dest view to imposing a > canonical ordering on widcarded rules. Could you explain that? Essentially because a lot of the firewall rules have the notion of "incoming" and "outgoing", and also because in most cases you will issue a single statement about both directions of traffic, such as "sendrecv" or "recvonly." Suppose for example that you want to write a rule that bars all incoming TCP connections. If you can tell "interior" and "exterior", you write: Rule ID: IA=*, EA=*, Proto=TCP, IPort=*, EPort=*, Attribute: bar incoming TCP If you can only reason about source and destination addresses, you have to explode that into multiple rules for the various address ranges. In the case of the Microsoft internal networks, which include quite a large list of different prefixes, you would probably end up with a few hundred of lines. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 7 23:30: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 ESMTP id XAA06470 for ; Fri, 7 Sep 2001 23:30: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 XAA07895; Fri, 7 Sep 2001 23:28:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07843 for ; Fri, 7 Sep 2001 23:28:35 -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 XAA06427 for ; Fri, 7 Sep 2001 23:27:08 -0400 (EDT) Message-ID: <20010908032712.80282.qmail@web13806.mail.yahoo.com> Received: from [66.89.112.150] by web13806.mail.yahoo.com via HTTP; Fri, 07 Sep 2001 20:27:12 PDT Date: Fri, 7 Sep 2001 20:27:12 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Terms needing definition or replacement To: Scott Brim , midcom@ietf.org In-Reply-To: <20010907130619.E1308@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: > On Fri, Sep 07, 2001 09:29:32AM -0700, Pyda Srisuresh allegedly wrote: > > > > --- Scott Brim wrote: > > > On Wed, Sep 05, 2001 10:58:23AM -0400, Melinda Shore allegedly wrote: > > > > Ruleset > > > > > > A set of rules which are installed and removed as a unit. A combination > > > of a filtering (matching) specification and one or more action > > > specifications. How complex these can be is not defined. > > > > > > (This is the generic I prefer. It's specific, it's not ambiguous, and > > > it includes all the functions of all the others, e.g. pinhole). > > > > > > > Rules are middlebox function specific. Filters in the case of a firewall > > and address maps and BINDs in the case of NAT. > > I think you're agreeing that "rule" is an appropriate generic term, but > disagreeing on "filter". Tell me if that's not true. Would "matching" Right. > be better than "filtering"? I do not like force-fitting all middlebox functions into the box of firewall-like ACL(or filter) based action devices. Why cant rules exist as address maps or port maps or in whatever form that is appropriate for the middlebix function? > > > > > Pinhole > > > > > > A ruleset where the main action specification is either to allow packets > > > to traverse the middlebox or to allow it through with address and/or > > > port translation. > > > > > > (If you want to keep using this word, I suggest separating out the two > > > different kinds of pinholes. "translated" versus "straight-through" > > > pinholes, maybe.) > > > > > > > A pinhole, in my mind, is simply a filtering rule - a specific tuple > > to be permitted or denied by a firewall. > > Exactly. A pinhole is the reification of a rule. The point I was trying to make is that the connotation of pinhole is limited to firewall-only, or at most to policy-based middlebox functions. I dont believe, this is a generic middlebox function term. > > > > > > > Connection > > > > > > Rewrite to eliminate all occurrences of this word. Don't assume any > > > state maintenance mechanism. > > > > > Agreed. I suggest replacing with "MIDCOM session" to be defined > > as follows. > > > > MIDCOM session is defined to be a lasting association between > > a MIDCOM agent and a middlebox. The MIDCOM session is not > > assumed to imply any specific transport layer protocol. > > Specifically, this should not be construed as refering to a > > connection-oriented TCP protocol. > > This looks good to me. With this definition we can keep 'session'. > OK. > > > > > > > > Pinhole-descriptor (the thing describing the state that's been > > > > created on the middlebox) > > > > > > Ruleset. > > > > > > > See my comment above. > > and my response. I'm not sure if you're saying > Right. This was a repeat term. Defined earlier. > > > > > > flow/resource > > > > > > Eliminate. > > > > > Are you saying, eliminate the definition of a middlebox resource > > (or) eliminate the discussion on middlebox resource? > > Eliminate the use of the term. I believe the way "resource" has been > used it's synonymous with "ruleset". That is, a bit of state which can > be installed or removed through the midcom protocol. > Disagree. The term resource can be an ACL, an address BIND, a port BIND or a NAT session descriptor etc. regards, suresh > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Sep 9 16:33:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13291 for ; Sun, 9 Sep 2001 16:33: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 QAA01115; Sun, 9 Sep 2001 16:32: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 QAA01041 for ; Sun, 9 Sep 2001 16:32:26 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13267 for ; Sun, 9 Sep 2001 16:30:45 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f89KW4v20056 for ; Sun, 9 Sep 2001 13:32:04 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-38.cisco.com [10.21.112.38]) by airborne.cisco.com (Mirapoint) with SMTP id AAW09026; Sun, 9 Sep 2001 13:31:40 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Sun, 9 Sep 2001 16:31:43 -0400 Date: Sun, 9 Sep 2001 16:31:42 -0400 From: Scott Brim To: midcom@ietf.org Message-ID: <20010909163142.D1680@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="jIfiFCH/TITHRwqa" Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [midcom] draft-brim-midcom-inandout-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 --jIfiFCH/TITHRwqa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I just sent this off to internet-drafts. Now I can answer all the mail from last week. More soon ... Scott --jIfiFCH/TITHRwqa Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-brim-midcom-inandout-00.txt" Network Working Group S. Brim Internet-Draft A. Simu Expires: January 30, 2002 Cisco Systems, Inc. August 2001 Midcom Agents and Topology draft-brim-midcom-inandout-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 30, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract A midcom agent does not know whether to ask for a ruleset to be installed in a middlebox or not. Even when it does ask, in some situations the middlebox does not know how to apply the ruleset. This document tries to solve these problems without adding an overwhelming amount of complexity to every agent and middlebox. Brim & Simu Expires January 30, 2002 [Page 1] Internet-Draft Midcom Agents and Topology August 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 4 4. The Simplest Scenario . . . . . . . . . . . . . . . . . . . 4 5. Overlapping Address Spaces . . . . . . . . . . . . . . . . . 5 5.1 Should a Request Be Sent? . . . . . . . . . . . . . . . . . 5 5.2 Inside or Outside? . . . . . . . . . . . . . . . . . . . . . 7 5.3 Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Agent on the Outside . . . . . . . . . . . . . . . . . . . . 8 7. More on Rulesets . . . . . . . . . . . . . . . . . . . . . . 8 8. Concatenated Addressing Realms . . . . . . . . . . . . . . . 9 9. Multiple Overlapping Address Spaces . . . . . . . . . . . . 10 10. Middleboxes and Discovery . . . . . . . . . . . . . . . . . 10 10.1 Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.2 Probing the Target Address . . . . . . . . . . . . . . . . . 11 10.3 Server Location Protocol . . . . . . . . . . . . . . . . . . 11 11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12. Security Considerations . . . . . . . . . . . . . . . . . . 13 References . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 Full Copyright Statement . . . . . . . . . . . . . . . . . . 15 Brim & Simu Expires January 30, 2002 [Page 2] Internet-Draft Midcom Agents and Topology August 2001 1. Introduction The IETF Midcom Working Group is defining a protocol (or extensions to one) by which an agent with application intelligence can request middleboxes to install specific sets of rules for packet matching and treatment [1][2]. The middleboxes of particular interest are NATs and firewalls. The goal is to make it possible to separate application intelligence from the actual handling of packets. The Midcom Working Group has encountered a problem in doing this separation -- any topology knowledge the middlebox might have, and any information regarding the security of the networks attached to its interfaces, is not directly available to the agent. The agent apparently needs this information to make decisions about when to make requests of middleboxes. This information could be made available but a brute force approach would make both functions more complex than they are now. What is the minimum amount of information that needs to be given to an agent? What approach minimizes overall system complexity? 2. Terminology All terminology is as in the Midcom Framework [1] with the following additions: Addressing Realm: A contiguous part of the Internet in which all used IP addresses are unique. Inside: In the same addressing realm as the entity being discussed. Outside: In a different addressing realm from the entity being discussed. Ruleset: A set of rules for middlebox packet processing which are installed and removed as a unit. In particular a ruleset includes at least one "filtering" or "matching" rule (e.g. any packet destined for 192.168.100.1 port 42) and at least one "action" rule (e.g. "let it through", "let it through with source address translation to 10.0.0.25", or "discard it"). Target Address: A source or destination IP address or address range in a rule. Informant Address: The address of the packet originator from which a target address was learned by the midcom agent. The mechanism by which the target address is conveyed from the informant to the agent is not relevant. The mechanism could be, for example, static configuration, a DNS reply or an application protocol Brim & Simu Expires January 30, 2002 [Page 3] Internet-Draft Midcom Agents and Topology August 2001 control packet. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. 3. The Problem In a network with a current NAT or firewall middlebox, the middlebox sits between an "inside" area and one or more "outside" areas. The middlebox applies rules to packets passing between the inside and outside areas (including the possibility of dropping them). The middlebox is configured to know whether a particular interface is connected to an inside or outside area. The middlebox also knows the egress interface for any packet it is supposed to forward -- if it didn't, the network administrator would have a problem and would arrange for it to have that information, either through configuration or through having the middlebox participate in routing in some way. However, the midcom agent may be physically separate from the middlebox. There are two problems with using the midcom framework as it is currently conceived. First a midcom agent will ask a middlebox to install rules for packets which the agent doesn't know for sure will ever pass through the middlebox in the first place. Second, it doesn't know how to tell the middlebox which interfaces on the outside of the middlebox should carry those packets. Proposed solutions range from hand-configuration to drastically reducing the Midcom Working Group's goals. 4. The Simplest Scenario Consider a very simple scenario to start. Suppose a single agent is controlling a single middlebox connecting two addressing realms, and the two address spaces do not overlap. The agent's client, an end system, wishes to initiate communication. If the packets are going to pass through the middlebox, a ruleset needs to be installed in the middlebox allowing them to do so. With current NATs and firewall middleboxes, application intelligence would be yet another function co-resident with the middlebox's NAT and/or firewall ones. Having all these functions, the middlebox would know what to do with any packet it received on any interface, and would not have to install any rules before the packets arrived. With Midcom, and separation of application intelligence from the middlebox functions, decision has to be made whether to install a ruleset for a particular packet before the packet arrives at the middlebox. What if the two endpoints are both on the same side of the middlebox? Brim & Simu Expires January 30, 2002 [Page 4] Internet-Draft Midcom Agents and Topology August 2001 In this particular case, since the address spaces do not overlap, no great harm is done by installing a ruleset, even if the communication it allegedly supports never passes through it. The only harm would be useless state information in the middlebox -- a large number of useless rulesets might block the installation of other, actually useful, rulesets. In this simple case, with moderate use, it is probably all right to use the mechanisms of the midcom protocol as currently conceived of in the Midcom Framework [1] -- no new capabilities are required. Heavy use does lead to the risk of exhausting middlebox resources uselessly, and a new approach is required. 5. Overlapping Address Spaces Consider a scenario like the one above except let the inside and outside realms have overlapping addresses. In order for communication to happen across the middlebox, both the inside and the outside endpoints need to be given non-overlapping addresses by the middlebox -- a classic chicken-and-egg problem. This is a "Twice NAT" scenario [4]. One mechanism for dealing with this, if necessary, is for an agent (or an endpoint) to request a globally unique address from its local middlebox, so that when others try to find that endpoint they will receive a useful address in response. Another mechanism is for a middlebox or an agent to monitor responses to DNS or other higher-layer requests, so that when an address for an endpoint or agent is being looked for, rulesets for address translation for the address being acquired can be installed in its local middlebox. If a NAT middlebox is monitoring DNS itself, it can just install its own ruleset. If a Midcom agent is doing the monitoring, then after it receives the response containing the target address it needs to send a request to the middlebox to have a ruleset installed for it. It uses the midcom protocol to do so. However, unlike the simple case in Section 4, there are problems here. The inside and outside address spaces overlap. The target address, for which a ruleset is being requested, might be valid in either realm. The middlebox has no way of knowing which addressing realm the agent is referring to. Also, unlike the previous case, in this case an unnecessary ruleset will be a security problem. We need to be sure that packets can only pass through the middlebox when appropriate. 5.1 Should a Request Be Sent? Several possible solutions for the problem of avoiding unnecessary rulesets have been proposed in the Midcom Working Group, including: Brim & Simu Expires January 30, 2002 [Page 5] Internet-Draft Midcom Agents and Topology August 2001 o The agent could listen in on the domain's routing protocol and only make a request of the middlebox when traffic would actually pass through the middlebox. Because of this the middlebox would assume that any address which was valid both inside and outside would refer to an outside address. First, this would add much more complexity to an agent than was intended by the Midcom concept. An agent should be able to be a small bit of software, perhaps resident in the same device as the middlebox function, or perhaps distributed with an application. Second, the knowledge that could be gained this way would be limited. The requirement in the general case is to learn whether a particular destination address is inside or outside from the point of view of a middlebox. A distance vector routing protocol would not carry this information at all, only the next hop to reach that address from the agent (which could be far from the middlebox). Even with a link state protocol, area boundaries abstract routing information. o The agent could query the middlebox for topology information available at the middlebox. This would require the middlebox to be able to dump a list of all network-layer prefixes on one side of it -- preferably the "inside". The agent would then avoid asking for rulesets for any destination covered by one of those prefixes. One problem with this approach is that routing might change with a network reconfiguration, but we could extend the protocol so that the middlebox could instruct the agent to refresh any topology information it might have. However, this approach would not reduce the complexity of the system at all -- it requires enough complexity at both ends of the midcom protocol that midcom as a whole would probably never be accepted by users. Finally, it adds a security issue because it requires the middlebox to prefer outside addresses to inside ones at all times. o The agent could use application-layer intelligence to determine if an endpoint is inside or outside. For example, a SIP proxy could parse the identifier of the callee to determine if it is within its trust boundaries, or keep track of which peers were "inside" and "outside" the trust boundary itself. This is a treacherous layer violation and is not robust. It may require constant monitoring to be sure that network layer configuration is matched in agent configuration. It may require a globally unique namespace for all administrative domains, something we don't have or need to have in the Internet today. We don't know how this layer violation will constrain our flexibility in the future. The application trust boundary need not correspond to the middlebox. Application entities can move around and register at IP addresses on different sides of the middlebox at unknown times. Finally, there is the required preference of outside addresses over inside Brim & Simu Expires January 30, 2002 [Page 6] Internet-Draft Midcom Agents and Topology August 2001 ones. In reality the agent only needs to know topology information with reference to the middlebox for one particular ruleset, for one particular time. The simplest approach is to have the agent not care whether its targets are inside or outside, and to always ask for a ruleset but allow for the middlebox to reply with two different kinds of "success" messages: first that the communication can go ahead because the ruleset is acceptable, and second that the communication can go ahead because from the point of view of the middlebox such a ruleset is unnecessary. This is a base for proceeding, but in itself it is not enough. 5.2 Inside or Outside? Just because the agent does not have to care if an address (or address range) is inside or outside, the middlebox still needs to know. The agent does not need to make that decision, but does hold information the middlebox needs to do so. It acquired this information when it acquired the target address. It must pass that information to the middlebox. The agent acquired its target addresses somehow. A target address may be statically configured in the agent, or the agent may acquire it through some other protocol (including DNS). In all cases, when it sends a target address to the middlebox as part of a rule, the way to make sure the middlebox has the proper context for interpreting that address is for the agent to include, with both source and destination target addresses, the "informant" address -- the address of the entity from which it acquired that target address. The "informant" address is locally unique in the address space shared by the agent and middlebox, and thus provides an absolutely sure way for the middlebox to know whether to interpret the target address in "inside" or "outside" context. If the target address was learned from an informant in another addressing realm on the other side of the middlebox, the informant's remote address will have been translated into a locally unique address. If the target address was learned from a target or an informant in the same addressing realm, the informant address could be the same as the target address, or perhaps be that of its local DNS server, or agent. If the target address is statically configured, the agent could list itself as the informant (note this would make it impossible for an "outside" address to be statically configured, although a statically configured locally unique translation of one could be). As a default rule of last resort, to Brim & Simu Expires January 30, 2002 [Page 7] Internet-Draft Midcom Agents and Topology August 2001 close off security problems, the middlebox can give precedence to inside addresses. Thus, in most cases the informant address is all the middlebox needs to determine the addressing realm in which the target address is to be interpreted. 5.3 Wildcards Sometimes an agent will want to install a matching rule for a source or destination range of addresses, for example in order to allow calls to come in to a server. Often any caller is acceptable and "inside" and "outside" do not matter. However, there will certainly be cases where an agent wants a server to be able to accept calls from a range of addresses only as long as they are "inside". We want to allow this restriction, and even default to it, but not require it. To handle this case, we add one more attribute to each of the addresses specified in matching rules: an "outside okay" flag, which says that an outside address is allowable, and that if an address is valid both inside and outside the middlebox, the outside should be chosen. 6. Agent on the Outside Consider the case where the agent is in a public realm (for example an ISP) and the two endpoints are in the same private realm. The same principles hold and no new mechanisms are necessary. The agent will have acquired the target addresses from an informant. The target addresses may only be meaningful in the informants' addressing realms, but the address for the informant will be unique and meaningful in the addressing realm shared by the agent and the middlebox. When the agent sends a ruleset request to the middlebox, specifying the target addresses and informant addresses, the informant addresses will allow the middlebox to determine that both the addresses are "outside", and it will respond that no ruleset installation is necessary. 7. More on Rulesets Because an agent usually does not know if a target address is inside or outside when it first passes it to the middlebox, rules cannot generally be phrased in terms of inside and outside addresses -- only whether an outside address is acceptable. Because directionality is important (for example, ports may differ), rules must be phrased in terms of source and destination. There was a proposal in the Midcom Working Group that the midcom protocol should include actual interfaces as attributes for addresses Brim & Simu Expires January 30, 2002 [Page 8] Internet-Draft Midcom Agents and Topology August 2001 in matching rules. Besides the fact that it is extremely complex for the agent to able to keep track of the middlebox's interfaces and what they are connected to, let alone specify them in a way that is mutually understandable, it is not necessary. If the agent includes the addresses of its informants and an "outside okay" flag, it tells the middlebox all it needs to know how to reach the target addresses and to determine if installing a ruleset is necessary. 8. Concatenated Addressing Realms There are several scenarios in which more than two addressing realms are involved. Suppose an agent is in one addressing realm and the two endpoints are reachable through two different middleboxes connected to that realm. The agent needs to install a ruleset in each middlebox. In this case the mechanism described above works well. Informant addresses, as received at the agent, are always unique and meaningful in the addressing realm of the agent. The agent sends the target addresses and informant addresses to each middlebox. At each middlebox one informant address will be "outside", and the associated target address will be interpreted as such, while the other will appear to be on the inside (the same side as the agent). The ruleset will be installed. The "informant address" technique will not work if the target addresses provided by informants are not meaningful to the relevant middleboxes -- for example, if an endpoint is more than one addressing realm away from the midcom agent and the informant provides an address which is only meaningful in the endpoint's local addressing realm. In order for an agent to establish connectivity between two endpoints, both of them need to be represented by IP addresses which are unique within the space in which they will be used. Fortunately it looks like the implementations and strategies proposed so far do follow this rule. A DNS server representing endpoints in a NATted addressing realm will respond with global addresses, and an agent can acquire a global (or at least non-local) address for its client in advance with the help of the middlebox and the midcom protocol as described here. Similarly, the "informant address" technique will not work if the agent is trying to control a middlebox through an intervening NAT. The agent and middlebox must share an addressing realm in order for the midcom protocol to be able to carry addresses as data meaningfully. Situations where it would be appropriate to run the midcom protocol through a NAT might not exist at all. Those networks would be less secure and more difficult to manage. If such situations did exist, an explicit fix would be to require what agents Brim & Simu Expires January 30, 2002 [Page 9] Internet-Draft Midcom Agents and Topology August 2001 seem to be inclined to do anyway, which is to acquire a global address for any client before it begins communicating. In the worst case, if nothing else is possible, a subsidiary controller can be installed in the address realm on the other side of the NAT. Given that these situations are unlikely, and that there are workarounds for both of them, elaborating the midcom protocol to provide general support for unlikely and probably undesirable situations is not worth the complexity it would require. 9. Multiple Overlapping Address Spaces There is a situation which is theoretically possible, but which current NATs don't handle. It may become possible in the future. Assume there is only one middlebox NAT function, but let it interface between more than two overlapping address spaces. This could be made possible using the "informant address" and "outside okay" mechanisms. 10. Middleboxes and Discovery The problem of finding the right middlebox to make requests of overlaps somewhat with how those requests are made, so we discuss the discovery problem briefly. Middlebox discovery is important in order to find a middlebox at all, to find a middlebox which is appropriate for the ruleset the agent wants to install, and to find a middlebox which can handle the expected load. Draft-lear-middlebox-discovery-requirements-00.txt [5] lists some requirements. One of those requirements was that no endpoint or agent should be required to participate in routing, which the scheme proposed here satisfies. 10.1 Anycast It might be possible to use anycast and avoid having any explicit discovery mechanism at all -- the agent would simply launch queries at an anycast address appropriate for middleboxes of a particular type. However, anycast literally finds any target. The only way to discriminate between middleboxes using anycast would be to use different addresses. It's very likely that we will want to be able to discriminate between middleboxes much more flexibly than just by IP address. For example some middleboxes might be connected to some outside realms while others were connected to others. Also, anycast is intended for one-time or at least short duration interactions, since if routing changes the destination found by an Brim & Simu Expires January 30, 2002 [Page 10] Internet-Draft Midcom Agents and Topology August 2001 anycast packet may change. This would be a problem for any association which has synchronized state. The midcom protocol already has a long-lasting association -- authentication/authorization and capability negotiation are done for the middlebox to start with, and it is expected that authentication/authorization for each request after that will depend on that initial exchange. 10.2 Probing the Target Address Tunnel Endpoint Discovery (TED) [6] is for finding IKE intermediaries. Its approach could possibly be reused. TED sends a special probe packet toward the target address, which is actually intended for any appropriate intermediary. If an authorized intermediary notices the packet it intercepts it and responds. A similar probe could be used to discover middleboxes. If there were multiple disjoint connections between the agent's domain and the outside world, this would ensure that the agent established an association with the appropriate middlebox for that particular needed ruleset. The problem with using special probes like this is the very basic issue that the agent should not have to know if a target address is inside or outside the middlebox. If the agent launches a probe toward an address which is on the same side of the middlebox, it will get no response. What has it learned then? TED is a different case, in that discovery of a tunnel endpoint is required for the service to be provided at all. 10.3 Server Location Protocol If middlebox discovery used SLP, a request for a middlebox "service" could be given detailed attributes, including the entire ruleset needed. A domain could create its own policies for deciding which middlebox a particular agent should use for a particular ruleset, and change them arbitrarily. In particular this arbitrariness would allow complex topologies, middleboxes with differing capabilities -- in series as well as in parallel -- and spontaneous changes in administrative relationships. Different outside domains could be reached via different middleboxes at different times of the day and so on. SLP uses multicast, which some may think is a problem. However in simple situations discovery is not necessary, as demonstrated above for simple scenarios, and in complex situations unicast SLP can be used. Brim & Simu Expires January 30, 2002 [Page 11] Internet-Draft Midcom Agents and Topology August 2001 Thus, SLP might be useful for middlebox discovery. The mechanisms proposed in this document do not have any architectural conflict with using SLP. The mechanisms proposed in this document do lead the agent to ask an SLS about every ruleset request. There are a number of possible means to cut back on SLP activity and to reduce the potential scaling problem. For example, the ability to ask SLP about ranges, the ability of the SLP responses to include ranges and TTLs, and the possibility of information being "pushed". If SLP is actually selected as a base for middlebox discovery, and the rate of SLP activity is seen as a problem, we could explore ways to make this approach scale. 11. Summary The problem is that an agent does not know whether to ask for a ruleset to be installed or not. To solve this problem without adding an overwhelming amount of complexity to every agent and middlebox: o The agent queries the middlebox about every possible ruleset. The agent does not have to know if packets for a particular association would pass through a middlebox or not. o In a query the agent says what the two endpoint addresses are that it will need to be able to establish an association between (wildcards are allowed). Each specific address or address range has associated with it an "outside okay" attribute and the address of the "informant" from which the agent learned that address. An informant address could be the address of the agent itself, for example in the case of static configuration, the address of some other helper, or the address of one of the endpoints. o The middlebox has a new type of reply to such queries, which is that the query has succeeded through no rules being necessary (since that association will not pass through the middlebox). This scheme adds no extra management burden, either locally or globally, nor does it add any of the concomitant security risk that extra configuration brings in a dynamic network environment. It does not threaten Internet scalability or robustness. It does not create new layer violations. It adds three simple pieces of information to the coalescing midcom protocol. Middlebox discovery is still a poorly explored area, but this scheme appears to work with middlebox discovery mechanisms at least as well Brim & Simu Expires January 30, 2002 [Page 12] Internet-Draft Midcom Agents and Topology August 2001 as any other proposal. There are restrictions on the applicability of this approach, but the cost of creating a protocol to cover the unusual scenarios which this approach does not is not worth paying. There are several loose ends to be explored, but none that call the basic protocol mechanisms into question. 12. Security Considerations The topology knowledge which a middlebox uses to make decisions about whether to install a ruleset or not is no more secure than the source of that knowledge, which is either configuration or routing protocols. The transfer of specific knowledge between the middlebox and the midcom agent is only as secure as the midcom protocol. There are requirements for mutual authentication of middlebox and agent. However, the protocol has not yet been specified or implemented and cannot be analyzed for security problems. The middlebox may be misled into opening up trust boundaries if "inside" versus "outside" is not explicitly indicated, or if an agent gets confused over the origin from which it learned a particular address. References [1] Srisuresh, P., Kuthan, J., Rosenberg, J. and A. Rayhan, "Middlebox Communication Architecture and framework", Internet Draft draft-ietf-midcom-framework-03.txt, July 2001. [2] Swale, R., Mart, P. and P. Sijben, "Middlebox Control (MIDCOM) Protocol Architecture and Requirements", Internet Draft draft- ietf-midcom-requirements-02.txt, July 2001. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Srisuresh, P. and M. Holdredge, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [5] Lear, E., "Requirements for Discovering Middleboxes", Internet Draft draft-lear-middlebox-discovery-requirements-00.txt, April 2001. [6] "Tunnel Endpoint Discovery Enhancement", February 2001, Brim & Simu Expires January 30, 2002 [Page 13] Internet-Draft Midcom Agents and Topology August 2001 . Authors' Addresses Scott Brim Cisco Systems, Inc. 146 Honness Lane Ithaca, NY 14850 USA EMail: sbrim@cisco.com Adina Simu Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: asimu@cisco.com Brim & Simu Expires January 30, 2002 [Page 14] Internet-Draft Midcom Agents and Topology August 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Brim & Simu Expires January 30, 2002 [Page 15] --jIfiFCH/TITHRwqa-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Sep 9 16:33:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13302 for ; Sun, 9 Sep 2001 16:33: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 QAA00948; Sun, 9 Sep 2001 16:30: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 QAA00912 for ; Sun, 9 Sep 2001 16:30:34 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13223 for ; Sun, 9 Sep 2001 16:28:53 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q131ATNM; Sun, 9 Sep 2001 16:29:50 -0400 Message-Id: <3.0.5.32.20010909162901.007cd9e0@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 09 Sep 2001 16:29:01 -0400 To: "Christian Huitema" , From: Mark Duffy In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] RE: Precedence of wildcards Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:23 PM 9/7/01 -0700, Christian Huitema wrote: >> Therefore I don't understand *why* the interior/exterior view of >> things lends itself any better than the source/dest view to imposing a >> canonical ordering on widcarded rules. Could you explain that? > >Essentially because a lot of the firewall rules have the notion of >"incoming" and "outgoing", and also because in most cases you will issue >a single statement about both directions of traffic, such as "sendrecv" >or "recvonly." > >Suppose for example that you want to write a rule that bars all incoming >TCP connections. If you can tell "interior" and "exterior", you write: > Rule ID: IA=*, EA=*, Proto=TCP, IPort=*, EPort=*, > Attribute: bar incoming TCP >If you can only reason about source and destination addresses, you have >to explode that into multiple rules for the various address ranges. In >the case of the Microsoft internal networks, which include quite a large >list of different prefixes, you would probably end up with a few hundred >of lines. > >-- Christian Huitema I don't see why, if using source/dest, such an explosion of rules would take place. Recallling that "realm" is also part of the equation, for the above case, one rule is also sufficient from source/dest perspective: Rule ID: Realm=realm-1, SA=*, DA=*, Proto=TCP, SPort=*, DPort=*, Attribute: bar incoming TCP Now, since the above example has wildcard for all the addresses and ports anyway, it is not too surprising that source/dest vs interior/exterior didn't matter. Suppose we had another, higher precedence policy to allow incoming TCP to port 80 on a particular server: With interior/exterior view the rule might be: Rule ID: Realm=realm-1, IA=1.2.3.4, EA=*, Proto=TCP, IPort=80, EPort=*, Attribute: allow incoming TCP With source/dest view the rule might be: Rule ID: Realm=realm-1, SA=* DA=1.2.3.4, Proto=TCP, SPort=*, DPort=80, Attribute: allow incoming TCP If we observe that the behavior of the FW-middlebox is that it allows the incoming TCP syns with the above 5-tuple, and as part of its stateful behavior it then also allows packets with the reverse 5-tuple (SA=1.2.3.4 DA=, Proto=TCP, SPort=80, DPort=) to flow in the opposite direction then again it appears to me that the source/dest and interior/exterior views are about equivalent. Can you provide a specific example where an explosion of rules would take place? Another consideration in whether the midcom protocol should have a source/dest or interior/exterion slant is compatibility with the existing base of middlebox devices. I would have guessed that most are oriented to source/dest, although I am saying that without much specific knowledge. --Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Sep 9 18:04:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13745 for ; Sun, 9 Sep 2001 18:04: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 SAA02575; Sun, 9 Sep 2001 18:03: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 SAA02546 for ; Sun, 9 Sep 2001 18:03:51 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13730 for ; Sun, 9 Sep 2001 18:02:11 -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 f89M39x17633 for ; Sun, 9 Sep 2001 15:03:09 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-275.cisco.com [10.21.113.19]) by airborne.cisco.com (Mirapoint) with SMTP id AAW09205; Sun, 9 Sep 2001 15:03:06 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Sun, 9 Sep 2001 18:03:12 -0400 Date: Sun, 9 Sep 2001 18:03:12 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] RE: Precedence of wildcards Message-ID: <20010909180312.A1512@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <3.0.5.32.20010909162901.007cd9e0@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.20010909162901.007cd9e0@email.quarrytech.com>; from mduffy@quarrytech.com on Sun, Sep 09, 2001 at 04:29:01PM -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 Sun, Sep 09, 2001 04:29:01PM -0400, Mark Duffy allegedly wrote: > At 12:23 PM 9/7/01 -0700, Christian Huitema wrote: > >Suppose for example that you want to write a rule that bars all incoming > >TCP connections. If you can tell "interior" and "exterior", you write: > > Rule ID: IA=*, EA=*, Proto=TCP, IPort=*, EPort=*, > > Attribute: bar incoming TCP > >If you can only reason about source and destination addresses, you have > >to explode that into multiple rules for the various address ranges. In > >the case of the Microsoft internal networks, which include quite a large > >list of different prefixes, you would probably end up with a few hundred > >of lines. First of all, unless you assume some external means for the agent to know, to start with, that its endpoint addresses are inside or outside, then not all ruleset requests can be phrased in these terms -- but they certainly can be phrased in terms of source and destination. Second, if you want to bar all TCP connections from crossing a middlebox, just bar all TCP connections. No discrimination between inside and outside is necessary or useful, so this example isn't very good for you. > I don't see why, if using source/dest, such an explosion of rules would > take place. Recallling that "realm" is also part of the equation, for the > above case, one rule is also sufficient from source/dest perspective: > Rule ID: Realm=realm-1, SA=*, DA=*, Proto=TCP, SPort=*, DPort=*, > Attribute: bar incoming TCP Mark, you're using "realm ID" in this case simply to mean "inside". Aside from the fact that this rule doesn't mean much (see above), your goal could easily be met by a simple flag, like the "outside okay" flag I suggested, as opposed to a system of realm identifiers and all they require. > Now, since the above example has wildcard for all the addresses and ports > anyway, it is not too surprising that source/dest vs interior/exterior > didn't matter. Suppose we had another, higher precedence policy to allow > incoming TCP to port 80 on a particular server: > > With interior/exterior view the rule might be: > Rule ID: Realm=realm-1, IA=1.2.3.4, EA=*, Proto=TCP, IPort=80, EPort=*, > Attribute: allow incoming TCP > > With source/dest view the rule might be: > Rule ID: Realm=realm-1, SA=* DA=1.2.3.4, Proto=TCP, SPort=*, DPort=80, > Attribute: allow incoming TCP > If we observe that the behavior of the FW-middlebox is that it allows the > incoming TCP syns with the above 5-tuple, and as part of its stateful > behavior it then also allows packets with the reverse 5-tuple (SA=1.2.3.4 > DA=, Proto=TCP, SPort=80, DPort=) to flow > in the opposite direction then again it appears to me that the source/dest > and interior/exterior views are about equivalent. Sure. > Another consideration in whether the midcom protocol should have a > source/dest or interior/exterion slant is compatibility with the existing > base of middlebox devices. I would have guessed that most are oriented to > source/dest, although I am saying that without much specific knowledge. Most implementations apparently use *both*. After all with overlapping address spaces a particular source could be either inside or outside. The question for me is whether an agent can have confidence in all cases about whether a particular address that it's concerned about is inside or outside. I think not. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Sep 9 18:09:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13772 for ; Sun, 9 Sep 2001 18:09: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 SAA02660; Sun, 9 Sep 2001 18:09:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02627 for ; Sun, 9 Sep 2001 18:09:33 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13762 for ; Sun, 9 Sep 2001 18:07:52 -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 f89M9Cv10670 for ; Sun, 9 Sep 2001 15:09:12 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-275.cisco.com [10.21.113.19]) by airborne.cisco.com (Mirapoint) with SMTP id AAW09216; Sun, 9 Sep 2001 15:08:48 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Sun, 9 Sep 2001 18:08:54 -0400 Date: Sun, 9 Sep 2001 18:08:54 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Topology considerations documents Message-ID: <20010909180854.B1512@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <008101c136d2$26055400$2300000a@acmepacket.com> <20010906133030.A1764@SBRIM-W2K> <007401c13702$d7b96bc0$2300000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <007401c13702$d7b96bc0$2300000a@acmepacket.com>; from bpenfield@acmepacket.com on Thu, Sep 06, 2001 at 02:36:27PM -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Thu, Sep 06, 2001 02:36:27PM -0400, Bob Penfield allegedly wrote: > How the midcom agents learn the realm names is not a midcom problem. It > could be through static configuration or some discovery protocol between the > entities sharing that realm naming scheme and namespace. This sounds a lot like economics discussions which begin with "First, we assume a perfect market" :-). Think about what you're assuming! Static configuration? See what I wrote about the management headaches and the possible security holes (which you wouldn't know about until after a violation occurred). Imagine an ISP with thousands of edge boxes that it needs to manage through these changes. Discovery protocol? For that to work, everyone would need to have something discoverable. You would need the world's only globally unique namespace, would require even casual users to get a name in order to make a call, and then you would need the discovery protocol itself -- or you would have to change every application signaling protocol in the Internet. More arguments about this later. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Sep 9 18:11:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13802 for ; Sun, 9 Sep 2001 18:11: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 SAA02739; Sun, 9 Sep 2001 18:12: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 SAA02708 for ; Sun, 9 Sep 2001 18:12:12 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13790 for ; Sun, 9 Sep 2001 18:10:31 -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 f89MBXx19312 for ; Sun, 9 Sep 2001 15:11:33 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-275.cisco.com [10.21.113.19]) by airborne.cisco.com (Mirapoint) with SMTP id AAW09224; Sun, 9 Sep 2001 15:11:27 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Sun, 9 Sep 2001 18:11:33 -0400 Date: Sun, 9 Sep 2001 18:11:32 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Terms needing definition or replacement Message-ID: <20010909181132.C1512@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <20010907130619.E1308@SBRIM-W2K> <20010908032712.80282.qmail@web13806.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: <20010908032712.80282.qmail@web13806.mail.yahoo.com>; from srisuresh@yahoo.com on Fri, Sep 07, 2001 at 08:27:12PM -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 Fri, Sep 07, 2001 08:27:12PM -0700, Pyda Srisuresh allegedly wrote: > > I think you're agreeing that "rule" is an appropriate generic term, but > > disagreeing on "filter". Tell me if that's not true. Would "matching" > > be better than "filtering"? > > I do not like force-fitting all middlebox functions into the box of > firewall-like ACL(or filter) based action devices. Why cant rules > exist as address maps or port maps or in whatever form that is > appropriate for the middlebix function? But ... address and port maps (in the NAT sense, right?) are not matching rules, they're action rules. A ruleset contains both. > > > > > flow/resource > > > > > > > > Eliminate. > > > > > > > Are you saying, eliminate the definition of a middlebox resource > > > (or) eliminate the discussion on middlebox resource? > > > > Eliminate the use of the term. I believe the way "resource" has been > > used it's synonymous with "ruleset". That is, a bit of state which can > > be installed or removed through the midcom protocol. > > > Disagree. The term resource can be an ACL, an address BIND, a port BIND > or a NAT session descriptor etc. I see. Then, could we use the more specific terms when we can? ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 11:14: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 ESMTP id LAA17902 for ; Mon, 10 Sep 2001 11:14: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 LAA04978; Mon, 10 Sep 2001 11:10:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04948 for ; Mon, 10 Sep 2001 11:10:39 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17738 for ; Mon, 10 Sep 2001 11:09:10 -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 f8AF8B115994 for ; Mon, 10 Sep 2001 08:08:11 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp6.cisco.com [10.21.64.6]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACT00048; Mon, 10 Sep 2001 08:10:06 -0700 (PDT) Message-Id: <5.1.0.14.0.20010910110010.00a531a0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 10 Sep 2001 11:11:53 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Terminology discussion - status Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org We made some progress last week, but not enough to close the discussion and edit the documents. Rules: Can we resolve the "rules" issue by adding text distinguishing between action rules and matching rules? Suresh is correct in pointing out that we don't want to be so restrictive in our terminology that the documents aren't applicable to other types of middleboxes, but at the same time we *are* focusing specifically on NATs and firewalls and we don't want to be so general that the language is meaningless. I think that if we describe what action rules are and matching rules are *without going into the details of their contents* we'll be well ahead of where we are now. Ruleset: Scott proposed a definition which hasn't yet received any discussion: "A set of rules which are installed and removed as a unit. A combination of a filtering (matching) specification and one or more action specifications. How complex these can be is not defined." Objections? Alternatives? Pinhole: There seems to be some sentiment that if the term is to be used at all, it's as an instantiation of a rule or ruleset. It is not an abstraction. Pinhole-descriptor: Likewise - it's just a ruleset. Connection: Them that's spoken have indicated a preference for "midcom session." Resource: We still need a definition here if we're to keep it. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 11:53:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19375 for ; Mon, 10 Sep 2001 11:53: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 LAA06167; Mon, 10 Sep 2001 11:46: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 LAA06137 for ; Mon, 10 Sep 2001 11:46: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 ESMTP id LAA19072 for ; Mon, 10 Sep 2001 11:45:23 -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 f8AFkQx09505 for ; Mon, 10 Sep 2001 08:46:26 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-25.cisco.com [10.21.96.25]) by airborne.cisco.com (Mirapoint) with SMTP id AAW13887; Mon, 10 Sep 2001 08:46:19 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 10 Sep 2001 11:46:24 -0400 Date: Mon, 10 Sep 2001 11:46:24 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Terminology discussion - status Message-ID: <20010910114624.S1376@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <5.1.0.14.0.20010910110010.00a531a0@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20010910110010.00a531a0@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Mon, Sep 10, 2001 at 11:11:53AM -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, Sep 10, 2001 11:11:53AM -0400, Melinda Shore allegedly wrote: > We made some progress last week, but not enough to close the > discussion and edit the documents. Mark, Suresh and I have been discussing offline. I think we're waiting for something from Mark right now, after which we can summarize to the group. > Rules: Can we resolve the "rules" issue by adding text distinguishing > between action rules and matching rules? Suresh is correct in pointing > out that we don't want to be so restrictive in our terminology that > the documents aren't applicable to other types of middleboxes, but at > the same time we *are* focusing specifically on NATs and firewalls and > we don't want to be so general that the language is meaningless. I > think that if we describe what action rules are and matching rules are > *without going into the details of their contents* we'll be well ahead > of where we are now. > > Ruleset: Scott proposed a definition which hasn't yet received any > discussion: "A set of rules which are installed and removed as a unit. > A combination of a filtering (matching) specification and one or more > action specifications. How complex these can be is not defined." > Objections? Alternatives? Just a small tweak which has come out: I would like to allow *one or more* filtering (matching) specifications. s/a/one or more/ > Pinhole: There seems to be some sentiment that if the term is to be > used at all, it's as an instantiation of a rule or ruleset. It is > not an abstraction. > > Pinhole-descriptor: Likewise - it's just a ruleset. > > Connection: Them that's spoken have indicated a preference for "midcom > session." > > Resource: We still need a definition here if we're to keep it. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 11:58:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19572 for ; Mon, 10 Sep 2001 11:58: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 LAA06268; Mon, 10 Sep 2001 11:52:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06238 for ; Mon, 10 Sep 2001 11:52:15 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19283 for ; Mon, 10 Sep 2001 11:50: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 LAA01501; Mon, 10 Sep 2001 11:52:11 -0400 (EDT) Message-Id: <200109101552.LAA01501@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Melinda Shore cc: midcom@ietf.org Subject: Re: [midcom] Terminology discussion - status In-reply-to: Your message of "Mon, 10 Sep 2001 11:11:53 EDT." <5.1.0.14.0.20010910110010.00a531a0@mira-sjc5-4.cisco.com> Date: Mon, 10 Sep 2001 11:52:11 -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 > Suresh is correct in pointing > out that we don't want to be so restrictive in our terminology that > the documents aren't applicable to other types of middleboxes, I don't think this is correct at all. The term 'middlebox' conflates so many different kinds of devices that it is essentially useless. The best thing this group could do is to discontinue use of the term entirely. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 11: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 ESMTP id LAA19588 for ; Mon, 10 Sep 2001 11:58: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 LAA06323; Mon, 10 Sep 2001 11:54: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 LAA06295 for ; Mon, 10 Sep 2001 11:54:12 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19357 for ; Mon, 10 Sep 2001 11:52:43 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q131A4N5; Mon, 10 Sep 2001 11:53:40 -0400 Message-Id: <3.0.5.32.20010910115254.00a08d30@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 10 Sep 2001 11:52:54 -0400 To: Melinda Shore , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Terminology discussion - status In-Reply-To: <5.1.0.14.0.20010910110010.00a531a0@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 Scott and I and Suresh had some side discussion on the terminology but didn't get to agreement. So, not claiming their endorsement, but acknowledging their input, I'll toss out the following terms to distinguish the components of rulesets: Filter Spec Packet classifier (matching) information that identifies a set of packets to be treated a certain way by a middlebox. Action Spec Description of the middlebox treatment/service to be applied to a set of packets. Ruleset The combination of one or more filter specs and one or more action specs. Packets matching the filter spec(s) are to be treated as specified by the associated action spec(s). The ruleset may also contain auxilliary information such as timeout values, owning agent, etc. [Scott/Melinda point out that the ruleset gets installed/removed/administered as a unit and I don't disagree but that seems to me to go beyond defining the terminology, and belongs elsewhere.] Pinhole -- eliminate this term if possible. Else: A behavior of a firewall-type middlebox to allow a specified set of packets to traverse the middlebox. Pinholes instigated via the midcom protocol are described by Rulesets. Pinhole-descriptor -- replace this term by Ruleset Flow -- eliminate use of this term. replace with the appropriate terms above. Resource -- ditto At 11:11 AM 9/10/01 -0400, Melinda Shore wrote: >We made some progress last week, but not enough to close the >discussion and edit the documents. > >Rules: Can we resolve the "rules" issue by adding text distinguishing >between action rules and matching rules? Suresh is correct in pointing >out that we don't want to be so restrictive in our terminology that >the documents aren't applicable to other types of middleboxes, but at >the same time we *are* focusing specifically on NATs and firewalls and >we don't want to be so general that the language is meaningless. I >think that if we describe what action rules are and matching rules are >*without going into the details of their contents* we'll be well ahead >of where we are now. > >Ruleset: Scott proposed a definition which hasn't yet received any >discussion: "A set of rules which are installed and removed as a unit. >A combination of a filtering (matching) specification and one or more >action specifications. How complex these can be is not defined." >Objections? Alternatives? > >Pinhole: There seems to be some sentiment that if the term is to be >used at all, it's as an instantiation of a rule or ruleset. It is >not an abstraction. > >Pinhole-descriptor: Likewise - it's just a ruleset. > >Connection: Them that's spoken have indicated a preference for "midcom >session." > >Resource: We still need a definition here if we're to keep it. > >Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 12:01:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19861 for ; Mon, 10 Sep 2001 12:01: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 MAA06981; Mon, 10 Sep 2001 12:00: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 MAA06811 for ; Mon, 10 Sep 2001 12:00:14 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19656 for ; Mon, 10 Sep 2001 11:58:45 -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 f8AG04v06773; Mon, 10 Sep 2001 09:00:04 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp6.cisco.com [10.21.64.6]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACV00671; Mon, 10 Sep 2001 08:59:41 -0700 (PDT) Message-Id: <5.1.0.14.0.20010910120111.00a66490@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 10 Sep 2001 12:01:27 -0400 To: Scott Brim , midcom mail-list From: Melinda Shore Subject: Re: [midcom] bullet updates? In-Reply-To: <20010910115412.T1376@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 11:54 AM 9/10/01 -0400, Scott Brim wrote: >So far the only bullet revisions I have this week are R6 and R81 being >deleted. Anything else I missed? Did you get these? R23: Accepted (my goof) R45: Delete R39, 63: keep R79, 80: Already resolved. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 12:05:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20214 for ; Mon, 10 Sep 2001 12:05: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 LAA06417; Mon, 10 Sep 2001 11:54:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06385 for ; Mon, 10 Sep 2001 11:54:53 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19371 for ; Mon, 10 Sep 2001 11:53:23 -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 f8AFqJ113362 for ; Mon, 10 Sep 2001 08:52:23 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-25.cisco.com [10.21.96.25]) by airborne.cisco.com (Mirapoint) with SMTP id AAW14002; Mon, 10 Sep 2001 08:54:07 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 10 Sep 2001 11:54:12 -0400 Date: Mon, 10 Sep 2001 11:54:12 -0400 From: Scott Brim To: midcom mail-list Message-ID: <20010910115412.T1376@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom mail-list Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [midcom] bullet updates? Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org So far the only bullet revisions I have this week are R6 and R81 being deleted. Anything else I missed? _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 12:41: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 ESMTP id MAA21866 for ; Mon, 10 Sep 2001 12:41:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08744; Mon, 10 Sep 2001 12:40: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 MAA08712 for ; Mon, 10 Sep 2001 12:40:16 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21684 for ; Mon, 10 Sep 2001 12:38:49 -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 f8AGZc112277 for ; Mon, 10 Sep 2001 09:37:45 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-25.cisco.com [10.21.96.25]) by airborne.cisco.com (Mirapoint) with SMTP id AAW14692; Mon, 10 Sep 2001 09:37:33 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 10 Sep 2001 12:37:39 -0400 Date: Mon, 10 Sep 2001 12:37:39 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Terminology discussion - status Message-ID: <20010910123739.V1376@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <5.1.0.14.0.20010910110010.00a531a0@mira-sjc5-4.cisco.com> <3.0.5.32.20010910115254.00a08d30@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.20010910115254.00a08d30@email.quarrytech.com>; from mduffy@quarrytech.com on Mon, Sep 10, 2001 at 11:52:54AM -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, Sep 10, 2001 11:52:54AM -0400, Mark Duffy allegedly wrote: > Scott and I and Suresh had some side discussion on the terminology but > didn't get to agreement. So, not claiming their endorsement, but > acknowledging their input, I'll toss out the following terms to distinguish > the components of rulesets: Heartily endorsed with one suggestion and two comments. > Filter Spec > Packet classifier (matching) information that identifies a set of > packets to be treated a certain way by a middlebox. > > Action Spec > Description of the middlebox treatment/service to be applied to a set of > packets. > > Ruleset > The combination of one or more filter specs and one or more action > specs. Packets matching the filter spec(s) are to be treated as specified > by the associated action spec(s). The ruleset may also contain auxilliary > information such as timeout values, owning agent, etc. > [Scott/Melinda point out that the ruleset gets > installed/removed/administered as a unit and I don't disagree but that > seems to me to go beyond defining the terminology, and belongs elsewhere.] [Well, I was just justifying saying that auxiliary information was attached to rulesets, not their components.] > Pinhole -- eliminate this term if possible. Else: > A behavior of a firewall-type middlebox to allow a specified set of > packets to traverse the middlebox. Pinholes instigated via the midcom > protocol are described by Rulesets. I would change "behavior" to "ruleset". I suggest that a ruleset *is* what gets installed, and the protocol carries descriptions of rulesets (which just might look exactly like the rulesets, but that's for son-of-midcom to decide). > Pinhole-descriptor -- replace this term by Ruleset > > Flow -- eliminate use of this term. replace with the appropriate terms above. > Resource -- ditto Clarification: We want to keep resource as a general term, but use the more specific terms whenever possible -- and so far it seems that we can use the more specific terms in every case except in the definition of "resource" which will be in the Framework. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 12:59:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22555 for ; Mon, 10 Sep 2001 12:59: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 MAA09049; Mon, 10 Sep 2001 12:56: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 MAA09019 for ; Mon, 10 Sep 2001 12:56:35 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22380 for ; Mon, 10 Sep 2001 12:55:07 -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 f8AGgx117291 for ; Mon, 10 Sep 2001 09:53:40 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-25.cisco.com [10.21.96.25]) by airborne.cisco.com (Mirapoint) with SMTP id AAW14827; Mon, 10 Sep 2001 09:44:55 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 10 Sep 2001 12:44:58 -0400 Date: Mon, 10 Sep 2001 12:44:58 -0400 From: Scott Brim To: midcom mail-list Subject: Re: [midcom] bullet updates? Message-ID: <20010910124458.W1376@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom mail-list References: <20010910115412.T1376@SBRIM-W2K> <5.1.0.14.0.20010910120111.00a66490@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20010910120111.00a66490@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Mon, Sep 10, 2001 at 12:01:27PM -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, Sep 10, 2001 12:01:27PM -0400, Melinda Shore allegedly wrote: > At 11:54 AM 9/10/01 -0400, Scott Brim wrote: > >So far the only bullet revisions I have this week are R6 and R81 being > >deleted. Anything else I missed? > > Did you get these? > > R23: Accepted (my goof) Already done in 0904. > R45: Delete OK, got it now. > R39, 63: keep R39 already in 0904. R63: OK, got it now. > R79, 80: Already resolved. Already done in 0904. Thanks ... Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 13:26: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 ESMTP id NAA23348 for ; Mon, 10 Sep 2001 13:26: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 NAA09831; Mon, 10 Sep 2001 13:22: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 NAA09802 for ; Mon, 10 Sep 2001 13:22:42 -0400 (EDT) Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23217 for ; Mon, 10 Sep 2001 13:21:14 -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 f8AGZlW02819; Mon, 10 Sep 2001 09:35:47 -0700 Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Sep 2001 10:21:19 -0700 Message-ID: From: John LaCour To: "'Mark Duffy'" , midcom@ietf.org Subject: RE: [midcom] RE: Precedence of wildcards Date: Mon, 10 Sep 2001 10:23:31 -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 > Mark Duffy wrote: > > Another consideration in whether the midcom protocol should have a > source/dest or interior/exterion slant is compatibility with > the existing > base of middlebox devices. I would have guessed that most > are oriented to > source/dest, although I am saying that without much specific > knowledge. I prefer interior/exterior because source and destination can be ambiguous with regard to whether you're talking about ip addresses in layer 3 packet headers or realms. They're often equivalent, but consider anti-spoofing packet filtering rules - in that case the source/destination addresses are opposite of the realm. I'm aware of more middlebox implementations which use some form of in/out or incoming/outgoing than source/destination when referring to the realm. Many use source and destination (ip address) when referring to the tuple contents for the matching rule itself however. It would be nice to have different terminology for where the rule gets applied and the contents of the rule itself. -John _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 13:33:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23525 for ; Mon, 10 Sep 2001 13:33: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 NAA10135; Mon, 10 Sep 2001 13:30: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 NAA10110 for ; Mon, 10 Sep 2001 13:30:21 -0400 (EDT) Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23385 for ; Mon, 10 Sep 2001 13:28:53 -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 f8AGhFW03127; Mon, 10 Sep 2001 09:43:16 -0700 Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Sep 2001 10:28:48 -0700 Message-ID: From: John LaCour To: "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] Terminology discussion - status Date: Mon, 10 Sep 2001 10:31:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Monday, September 10, 2001 8:12 AM > To: midcom@ietf.org > Subject: [midcom] Terminology discussion - status > > > Ruleset: Scott proposed a definition which hasn't yet received any > discussion: "A set of rules which are installed and removed > as a unit. > A combination of a filtering (matching) specification and one or more > action specifications. How complex these can be is not defined." > Objections? Alternatives? By action we mean "deny", "permit", "nat", "natpt" right? If so, I'm ok with this definition. > Pinhole: There seems to be some sentiment that if the term is to be > used at all, it's as an instantiation of a rule or ruleset. It is > not an abstraction. Agreed. > Pinhole-descriptor: Likewise - it's just a ruleset. I don't like this, it might be confused to be some sort of identifier for a MIDCOM request for a Ruleset. > Connection: Them that's spoken have indicated a preference for "midcom > session." Agreed with this preference. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 13:39:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23729 for ; Mon, 10 Sep 2001 13:39: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 NAA10344; Mon, 10 Sep 2001 13:35: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 NAA10315 for ; Mon, 10 Sep 2001 13:35:30 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23563 for ; Mon, 10 Sep 2001 13:34:02 -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 f8AHZ3x23123 for ; Mon, 10 Sep 2001 10:35:03 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-25.cisco.com [10.21.96.25]) by airborne.cisco.com (Mirapoint) with SMTP id AAW15874; Mon, 10 Sep 2001 10:34:57 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 10 Sep 2001 13:35:03 -0400 Date: Mon, 10 Sep 2001 13:35:02 -0400 From: Scott Brim To: midcom mail-list Message-ID: <20010910133502.A1376@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom mail-list Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [midcom] new requirements bullets, 010910 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org A new version of the requirements bullets is available at . _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 13:59:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24525 for ; Mon, 10 Sep 2001 13:59: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 NAA10550; Mon, 10 Sep 2001 13:45: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 NAA10518 for ; Mon, 10 Sep 2001 13:45:20 -0400 (EDT) Received: from INET-VRS-07.redmond.corp.microsoft.com ([131.107.3.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23930 for ; Mon, 10 Sep 2001 13:43:52 -0400 (EDT) Received: from 157.54.9.104 by INET-VRS-07.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 Sep 2001 10:44:16 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Sep 2001 10:44:12 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Sep 2001 10:44:00 -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, 10 Sep 2001 10:43:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Terminology discussion - status Date: Mon, 10 Sep 2001 10:43:26 -0700 Message-ID: Thread-Topic: [midcom] Terminology discussion - status Thread-Index: AcE6EoPu0KZ6Ga9AS4i2qzdGr3YzPwADPbwA From: "Christian Huitema" To: "Mark Duffy" , "Melinda Shore" , X-OriginalArrivalTime: 10 Sep 2001 17:43:26.0948 (UTC) FILETIME=[189E5A40:01C13A20] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA10519 Sender: 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 We are missing something like a "ruleset type" that defines the type of rule and action being considered; we may want to just focus on the "5-tuple", but having explicit typing will provide the extensibility that some required. By the way, ruleset is kind of hideous. I would prefer to replace all occurrences of ruleset by pinhole... > Filter Spec > Packet classifier (matching) information that identifies a set of > packets to be treated a certain way by a middlebox. This is fine. > Action Spec > Description of the middlebox treatment/service to be applied to a > set of > packets. I think that "action spec" is too restrictive. You want something like "attributes." Consider as a possible attribute the identity of the agent who created the ruleset; this is a useful parameter for access control, but it definitely does not define an "action." > Ruleset > The combination of one or more filter specs and one or more action > specs. Packets matching the filter spec(s) are to be treated as > specified > by the associated action spec(s). The ruleset may also contain > auxilliary > information such as timeout values, owning agent, etc. Should add the "ruleset type" to the list. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 14:05: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 ESMTP id OAA24843 for ; Mon, 10 Sep 2001 14:05: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 NAA10702; Mon, 10 Sep 2001 13:58: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 NAA10668 for ; Mon, 10 Sep 2001 13:58:34 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24437 for ; Mon, 10 Sep 2001 13:57:06 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q131A4XY; Mon, 10 Sep 2001 13:58:04 -0400 Message-Id: <3.0.5.32.20010910135716.007ce100@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 10 Sep 2001 13:57:16 -0400 To: Scott Brim , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Terminology discussion - status In-Reply-To: <20010910123739.V1376@SBRIM-W2K> References: <3.0.5.32.20010910115254.00a08d30@email.quarrytech.com> <5.1.0.14.0.20010910110010.00a531a0@mira-sjc5-4.cisco.com> <3.0.5.32.20010910115254.00a08d30@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:37 PM 9/10/01 -0400, Scott Brim wrote: ... >> Pinhole -- eliminate this term if possible. Else: >> A behavior of a firewall-type middlebox to allow a specified set of >> packets to traverse the middlebox. Pinholes instigated via the midcom >> protocol are described by Rulesets. > >I would change "behavior" to "ruleset". I suggest that a ruleset *is* >what gets installed, and the protocol carries descriptions of rulesets >(which just might look exactly like the rulesets, but that's for >son-of-midcom to decide). Scott, I believe you are viewing "pinhole" as a particular type of ruleset, while I was viewing "pinhole" as the reification (great word I learned from you this week!) of such a ruleset. I.e. I was thinking of it being the state installed into the middlebox as a result of the ruleset being transmitted to it. Of course either one can be correct since it is a matter of definition! Or we can have a term for each definition (FW-pinhole, pinhole-ruleset?). Or hopefully, we can just get rid of it entirely ;-) --Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 14:22: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 ESMTP id OAA25807 for ; Mon, 10 Sep 2001 14: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 OAA12432; Mon, 10 Sep 2001 14:15: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 OAA12403 for ; Mon, 10 Sep 2001 14:15:23 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25471 for ; Mon, 10 Sep 2001 14:13:55 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A3381734012A; Mon, 10 Sep 2001 14:15:20 -0400 Message-ID: <009901c13a24$59c1eec0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Melinda Shore" , , "Mark Duffy" References: <3.0.5.32.20010910115254.00a08d30@email.quarrytech.com> Subject: Re: [midcom] Terminology discussion - status Date: Mon, 10 Sep 2001 14:13: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 Sender: 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: "Mark Duffy" To: "Melinda Shore" ; Sent: Monday, September 10, 2001 11:52 AM Subject: Re: [midcom] Terminology discussion - status > Scott and I and Suresh had some side discussion on the terminology but > didn't get to agreement. So, not claiming their endorsement, but > acknowledging their input, I'll toss out the following terms to distinguish > the components of rulesets: > > > Filter Spec > Packet classifier (matching) information that identifies a set of > packets to be treated a certain way by a middlebox. > > Action Spec > Description of the middlebox treatment/service to be applied to a set of > packets. > > Ruleset > The combination of one or more filter specs and one or more action > specs. Packets matching the filter spec(s) are to be treated as specified > by the associated action spec(s). The ruleset may also contain auxilliary > information such as timeout values, owning agent, etc. > [Scott/Melinda point out that the ruleset gets > installed/removed/administered as a unit and I don't disagree but that > seems to me to go beyond defining the terminology, and belongs elsewhere.] > > > Pinhole -- eliminate this term if possible. Else: > A behavior of a firewall-type middlebox to allow a specified set of > packets to traverse the middlebox. Pinholes instigated via the midcom > protocol are described by Rulesets. > > Pinhole-descriptor -- replace this term by Ruleset > > Flow -- eliminate use of this term. replace with the appropriate terms above. > Resource -- ditto Both flow & resource are generic terms and we should not use them for protocol elements, but that does not mean we eliminate every occurance of the words in the docs. By generic I mean we can say "The midcom protocol enables application flows to traverse a middlebox by installing rulesets ....". > > > At 11:11 AM 9/10/01 -0400, Melinda Shore wrote: > >We made some progress last week, but not enough to close the > >discussion and edit the documents. > > > >Rules: Can we resolve the "rules" issue by adding text distinguishing > >between action rules and matching rules? Suresh is correct in pointing > >out that we don't want to be so restrictive in our terminology that > >the documents aren't applicable to other types of middleboxes, but at > >the same time we *are* focusing specifically on NATs and firewalls and > >we don't want to be so general that the language is meaningless. I > >think that if we describe what action rules are and matching rules are > >*without going into the details of their contents* we'll be well ahead > >of where we are now. > > > >Ruleset: Scott proposed a definition which hasn't yet received any > >discussion: "A set of rules which are installed and removed as a unit. > >A combination of a filtering (matching) specification and one or more > >action specifications. How complex these can be is not defined." > >Objections? Alternatives? > > > >Pinhole: There seems to be some sentiment that if the term is to be > >used at all, it's as an instantiation of a rule or ruleset. It is > >not an abstraction. > > > >Pinhole-descriptor: Likewise - it's just a ruleset. > > > >Connection: Them that's spoken have indicated a preference for "midcom > >session." > > > >Resource: We still need a definition here if we're to keep it. > > > >Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 14:28: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 ESMTP id OAA26044 for ; Mon, 10 Sep 2001 14:28: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 OAA12977; Mon, 10 Sep 2001 14:24: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 OAA12946 for ; Mon, 10 Sep 2001 14:24: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 ESMTP id OAA25862 for ; Mon, 10 Sep 2001 14:23:02 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q131A4ZX; Mon, 10 Sep 2001 14:23:59 -0400 Message-Id: <3.0.5.32.20010910142257.00a29860@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 10 Sep 2001 14:22:57 -0400 To: "Christian Huitema" , From: Mark Duffy Subject: RE: [midcom] Terminology discussion - status 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 10:43 AM 9/10/01 -0700, Christian Huitema wrote: >We are missing something like a "ruleset type" that defines the type of >rule and action being considered; we may want to just focus on the >"5-tuple", but having explicit typing will provide the extensibility >that some required. By the way, ruleset is kind of hideous. I would >prefer to replace all occurrences of ruleset by pinhole... I believe a lot of folks on the list find "pinhole" too firewall-specific. >> Filter Spec >> Packet classifier (matching) information that identifies a set of >> packets to be treated a certain way by a middlebox. > >This is fine. > >> Action Spec >> Description of the middlebox treatment/service to be applied to a >> set of >> packets. > >I think that "action spec" is too restrictive. You want something like >"attributes." Consider as a possible attribute the identity of the agent >who created the ruleset; this is a useful parameter for access control, >but it definitely does not define an "action." See the following definition which says the ruleset may have auxiliary info besides filter specs and action specs, including "owning agent" (shorthand for "agent who created the ruleset"). Does that address your point? Is it important to you that these other types of attributes be part of the "Action spec" vs just being part of the overall ruleset? I fear this is all getting a bit too detailed and specific, given that the objective here is to define terms for use in requirements/framework and not to define the protocol. > >> Ruleset >> The combination of one or more filter specs and one or more action >> specs. Packets matching the filter spec(s) are to be treated as >> specified >> by the associated action spec(s). The ruleset may also contain >> auxilliary >> information such as timeout values, owning agent, etc. > >Should add the "ruleset type" to the list. OK. > >-- Christian Huitema > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 14:33:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26332 for ; Mon, 10 Sep 2001 14:33: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 OAA13430; Mon, 10 Sep 2001 14:30:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13401 for ; Mon, 10 Sep 2001 14:30:22 -0400 (EDT) Received: from INET-VRS-07.redmond.corp.microsoft.com ([131.107.3.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26074 for ; Mon, 10 Sep 2001 14:28:52 -0400 (EDT) Received: from 157.54.9.108 by INET-VRS-07.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 Sep 2001 11:29:49 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Sep 2001 11:29:48 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Sep 2001 11:29:46 -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, 10 Sep 2001 11:29:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Terminology discussion - status Date: Mon, 10 Sep 2001 11:29:12 -0700 Message-ID: Thread-Topic: [midcom] Terminology discussion - status Thread-Index: AcE6JgzWqVtONck5RjabcwGOyVYO1wAAFkQQ From: "Christian Huitema" To: "Mark Duffy" , X-OriginalArrivalTime: 10 Sep 2001 18:29:12.0932 (UTC) FILETIME=[7D5A4240:01C13A26] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA13402 Sender: 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 think that "action spec" is too restrictive. You want something > like > >"attributes." Consider as a possible attribute the identity of the > agent > >who created the ruleset; this is a useful parameter for access > control, > >but it definitely does not define an "action." > > See the following definition which says the ruleset may have auxiliary > info > besides filter specs and action specs, including "owning agent" > (shorthand > for "agent who created the ruleset"). Does that address your point? > Is it > important to you that these other types of attributes be part of the > "Action spec" vs just being part of the overall ruleset? > > I fear this is all getting a bit too detailed and specific, given that > the > objective here is to define terms for use in requirements/framework > and not > to define the protocol. Frankly, I don't know what the action spec is. I have a hard time instantiating it, and I suspect it is useless in the main application, firewall and nat traversal. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 14:39:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26518 for ; Mon, 10 Sep 2001 14:39: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 OAA14090; Mon, 10 Sep 2001 14:38: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 OAA14059 for ; Mon, 10 Sep 2001 14:38:35 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26466 for ; Mon, 10 Sep 2001 14:37:06 -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 f8AIc4x02144 for ; Mon, 10 Sep 2001 11:38:04 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-25.cisco.com [10.21.96.25]) by airborne.cisco.com (Mirapoint) with SMTP id AAW17456; Mon, 10 Sep 2001 11:38:03 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 10 Sep 2001 14:38:08 -0400 Date: Mon, 10 Sep 2001 14:38:08 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Terminology discussion - status Message-ID: <20010910143808.C1376@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <3.0.5.32.20010910115254.00a08d30@email.quarrytech.com> <5.1.0.14.0.20010910110010.00a531a0@mira-sjc5-4.cisco.com> <3.0.5.32.20010910115254.00a08d30@email.quarrytech.com> <20010910123739.V1376@SBRIM-W2K> <3.0.5.32.20010910135716.007ce100@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.20010910135716.007ce100@email.quarrytech.com>; from mduffy@quarrytech.com on Mon, Sep 10, 2001 at 01:57:16PM -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, Sep 10, 2001 01:57:16PM -0400, Mark Duffy allegedly wrote: > At 12:37 PM 9/10/01 -0400, Scott Brim wrote: > ... > >> Pinhole -- eliminate this term if possible. Else: > >> A behavior of a firewall-type middlebox to allow a specified set of > >> packets to traverse the middlebox. Pinholes instigated via the midcom > >> protocol are described by Rulesets. > > > >I would change "behavior" to "ruleset". I suggest that a ruleset *is* > >what gets installed, and the protocol carries descriptions of rulesets > >(which just might look exactly like the rulesets, but that's for > >son-of-midcom to decide). > > Scott, I believe you are viewing "pinhole" as a particular type of ruleset, > while I was viewing "pinhole" as the reification (great word I learned from > you this week!) of such a ruleset. I.e. I was thinking of it being the > state installed into the middlebox as a result of the ruleset being > transmitted to it. Either way is fine with me. Depending on whether "ruleset" refers to a protocol element, some state in a middlebox, or an abstraction, terms for the others will fall out. I have no problem with "ruleset" being what gets carried in the protocol. However, in that case what's the general term for what gets installed in a middlebox as a result of its receiving a ruleset? > Of course either one can be correct since it is a matter of definition! Or > we can have a term for each definition (FW-pinhole, pinhole-ruleset?). Or > hopefully, we can just get rid of it entirely ;-) Some human groups can name every tree in their area but don't have a word for "tree". ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 14:45:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26760 for ; Mon, 10 Sep 2001 14:45: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 OAA14161; Mon, 10 Sep 2001 14:39: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 OAA14128 for ; Mon, 10 Sep 2001 14:39:24 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26487 for ; Mon, 10 Sep 2001 14:37:55 -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 f8AIcqx02832 for ; Mon, 10 Sep 2001 11:38:52 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-25.cisco.com [10.21.96.25]) by airborne.cisco.com (Mirapoint) with SMTP id AAW17475; Mon, 10 Sep 2001 11:38:50 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 10 Sep 2001 14:38:55 -0400 Date: Mon, 10 Sep 2001 14:38:55 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Terminology discussion - status Message-ID: <20010910143855.D1376@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <3.0.5.32.20010910115254.00a08d30@email.quarrytech.com> <009901c13a24$59c1eec0$2300000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <009901c13a24$59c1eec0$2300000a@acmepacket.com>; from bpenfield@acmepacket.com on Mon, Sep 10, 2001 at 02:13:53PM -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, Sep 10, 2001 02:13:53PM -0400, Bob Penfield allegedly wrote: > Both flow & resource are generic terms and we should not use them for > protocol elements, but that does not mean we eliminate every occurance of > the words in the docs. By generic I mean we can say "The midcom protocol > enables application flows to traverse a middlebox by installing rulesets > ....". Agreed. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 14:53: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 ESMTP id OAA27023 for ; Mon, 10 Sep 2001 14:53:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14458; Mon, 10 Sep 2001 14:41: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 OAA14429 for ; Mon, 10 Sep 2001 14:41:55 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26586 for ; Mon, 10 Sep 2001 14:40:26 -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 f8AIfSx05282; Mon, 10 Sep 2001 11:41:28 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-tmp6.cisco.com [10.21.64.6]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACW05962; Mon, 10 Sep 2001 11:41:20 -0700 (PDT) Message-Id: <5.1.0.14.0.20010910143656.00a68160@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 10 Sep 2001 14:43:04 -0400 To: "Christian Huitema" , From: Melinda Shore Subject: RE: [midcom] Terminology discussion - status 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:29 AM 9/10/01 -0700, Christian Huitema wrote: >Frankly, I don't know what the action spec is. I have a hard time >instantiating it, and I suspect it is useless in the main application, >firewall and nat traversal. An action spec is a "command" (install, delete, modify, etc.). I still don't like this approach, but there has been some feeling for having commands as parameters rather than as, uh, commands. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 14:53:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27038 for ; Mon, 10 Sep 2001 14: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 OAA14655; Mon, 10 Sep 2001 14:49: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 OAA14618 for ; Mon, 10 Sep 2001 14:49: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 ESMTP id OAA26815 for ; Mon, 10 Sep 2001 14:47:40 -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 f8AImsv13674; Mon, 10 Sep 2001 11:48:55 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-25.cisco.com [10.21.96.25]) by airborne.cisco.com (Mirapoint) with SMTP id AAW17721; Mon, 10 Sep 2001 11:48:30 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 10 Sep 2001 14:48:35 -0400 Date: Mon, 10 Sep 2001 14:48:35 -0400 From: Scott Brim To: Christian Huitema Cc: Mark Duffy , Melinda Shore , midcom@ietf.org Subject: Re: [midcom] Terminology discussion - status Message-ID: <20010910144835.E1376@SBRIM-W2K> Mail-Followup-To: Scott Brim , Christian Huitema , Mark Duffy , Melinda Shore , 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 huitema@windows.microsoft.com on Mon, Sep 10, 2001 at 10:43:26AM -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, Sep 10, 2001 10:43:26AM -0700, Christian Huitema allegedly wrote: > We are missing something like a "ruleset type" that defines the type of > rule and action being considered; we may want to just focus on the > "5-tuple", but having explicit typing will provide the extensibility > that some required. By the way, ruleset is kind of hideous. I would > prefer to replace all occurrences of ruleset by pinhole... > > > Filter Spec > > Packet classifier (matching) information that identifies a set of > > packets to be treated a certain way by a middlebox. > > This is fine. > > > Action Spec > > Description of the middlebox treatment/service to be applied to a > > set of > > packets. > > I think that "action spec" is too restrictive. You want something like > "attributes." Consider as a possible attribute the identity of the agent > who created the ruleset; this is a useful parameter for access control, > but it definitely does not define an "action." Rulesets are installed as a unit. Attributes belong to the ruleset, not to a particular rule which came as part of it. > > Ruleset > > The combination of one or more filter specs and one or more action > > specs. Packets matching the filter spec(s) are to be treated as > > specified > > by the associated action spec(s). The ruleset may also contain > > auxilliary > > information such as timeout values, owning agent, etc. > > Should add the "ruleset type" to the list. Where would you use this? There is only one ruleset type that I can think of, which is a group of at least one filter spec and at least one action spec. Are you saying, for example, you would want a "pinhole" ruleset type? That would be a ruleset with a pinhole action rule. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 14:58: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 ESMTP id OAA27173 for ; Mon, 10 Sep 2001 14:58: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 OAA14864; Mon, 10 Sep 2001 14:55: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 OAA14830 for ; Mon, 10 Sep 2001 14:55:17 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27051 for ; Mon, 10 Sep 2001 14:53:48 -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 f8AIskx20707 for ; Mon, 10 Sep 2001 11:54:46 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-25.cisco.com [10.21.96.25]) by airborne.cisco.com (Mirapoint) with SMTP id AAW17904; Mon, 10 Sep 2001 11:54:39 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 10 Sep 2001 14:54:44 -0400 Date: Mon, 10 Sep 2001 14:54:43 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Terminology discussion - status Message-ID: <20010910145443.F1376@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 huitema@windows.microsoft.com on Mon, Sep 10, 2001 at 11:29:12AM -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, Sep 10, 2001 11:29:12AM -0700, Christian Huitema allegedly wrote: > Frankly, I don't know what the action spec is. I have a hard time > instantiating it, and I suspect it is useless in the main application, > firewall and nat traversal. Examples: "Let the packet through" (that's your standard firewall pinhole). "Translate the source address/port to 192.69.1.201/42". "Encapsulate in XML and divert to that OPES service over there" (oops, did I say that?). This is not unusual stuff. Think in terms of sed. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 15:12:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27656 for ; Mon, 10 Sep 2001 15:12: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 PAA15516; Mon, 10 Sep 2001 15:08: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 PAA15485 for ; Mon, 10 Sep 2001 15:08:22 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27478 for ; Mon, 10 Sep 2001 15:06:53 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q131A492; Mon, 10 Sep 2001 15:07:47 -0400 Message-Id: <3.0.5.32.20010910150702.00a253c0@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 10 Sep 2001 15:07:02 -0400 To: John LaCour , midcom@ietf.org From: Mark Duffy Subject: RE: [midcom] RE: Precedence of wildcards 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 10:23 AM 9/10/01 -0700, John LaCour wrote: >> Mark Duffy wrote: >> >> Another consideration in whether the midcom protocol should have a >> source/dest or interior/exterion slant is compatibility with >> the existing >> base of middlebox devices. I would have guessed that most >> are oriented to >> source/dest, although I am saying that without much specific >> knowledge. > >I prefer interior/exterior because source and destination can be >ambiguous with regard to whether you're talking about ip addresses >in layer 3 packet headers or realms. They're often equivalent, but >consider anti-spoofing packet filtering rules - in that case the >source/destination addresses are opposite of the realm. > >I'm aware of more middlebox implementations which use some form >of in/out or incoming/outgoing than source/destination when referring >to the realm. Many use source and destination (ip address) when >referring to the tuple contents for the matching rule itself however. > >It would be nice to have different terminology for where the rule >gets applied and the contents of the rule itself. > >-John Hmm. The way I had been looking at this (but maybe it's just my own prejudice) was that the ruleset has the filter (matching) part and the action (what to do) part: I had been thinking that the filter part specifies "which" packets. The information involved could be subdivided into at least: a) attributes of the packets themselves e.g. source/dest address, protocol, src/dest ports. b) the domain boundary on which packets should be tested against the filter. I.e. at which middlebox and on which of the realms supported by that mb. (But by the time the agent is talking midcom to the middlebox, the "which middlebox" is already resolved.) I figure the action part carries the directionality as part of the "what to do", e.g permit-inbound, permit-outbound, NAT, etc. -Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 15:57:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29227 for ; Mon, 10 Sep 2001 15:57: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 PAA16489; Mon, 10 Sep 2001 15:44: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 PAA16413 for ; Mon, 10 Sep 2001 15:44:02 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28704 for ; Mon, 10 Sep 2001 15:42:33 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q131AVA4; Mon, 10 Sep 2001 15:43:28 -0400 Message-Id: <3.0.5.32.20010910154242.009ee6f0@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 10 Sep 2001 15:42:42 -0400 To: Melinda Shore , "Christian Huitema" , From: Mark Duffy Subject: RE: [midcom] Terminology discussion - status In-Reply-To: <5.1.0.14.0.20010910143656.00a68160@mira-sjc5-4.cisco.com> 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 02:43 PM 9/10/01 -0400, Melinda Shore wrote: >At 11:29 AM 9/10/01 -0700, Christian Huitema wrote: >>Frankly, I don't know what the action spec is. I have a hard time >>instantiating it, and I suspect it is useless in the main application, >>firewall and nat traversal. > >An action spec is a "command" (install, delete, modify, etc.). >I still don't like this approach, but there has been some feeling >for having commands as parameters rather than as, uh, commands. > >Melinda Melinda, that was not my understanding or intent. Although we haven't defined "command", I infer from your context that you are refering to "commands" (install, delete, modify, etc.) an Agent might send to a middlebox. The Action spec is *not* such a "command". "Action Spec: Description of the middlebox treatment/service to be applied to a set of packets." Action spec is part of a ruleset and says what the middlebox should do to packets that match the filter spec associated with the ruleset. Action spec is not a command sent from an agent to a middlebox, nor does it contain a command sent from an agent to a middlebox. I would expect that a Ruleset would be an *argument* to such a command --Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 16:06:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29489 for ; Mon, 10 Sep 2001 16:06: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 QAA17115; Mon, 10 Sep 2001 16:05: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 QAA17086 for ; Mon, 10 Sep 2001 16:05:02 -0400 (EDT) Received: from INET-VRS-07.redmond.corp.microsoft.com ([131.107.3.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29451 for ; Mon, 10 Sep 2001 16:03:32 -0400 (EDT) Received: from 157.54.9.104 by INET-VRS-07.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 Sep 2001 13:04:30 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Sep 2001 13:04:30 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Sep 2001 13:04:29 -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, 10 Sep 2001 13:03:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Terminology discussion - status Date: Mon, 10 Sep 2001 13:03:54 -0700 Message-ID: Thread-Topic: [midcom] Terminology discussion - status Thread-Index: AcE6KuWk8KEhZ9/bQLSppLqS5e/hXwACBiVg From: "Christian Huitema" To: "Scott Brim" , X-OriginalArrivalTime: 10 Sep 2001 20:03:55.0472 (UTC) FILETIME=[B8690D00:01C13A33] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA17087 Sender: 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 > > Frankly, I don't know what the action spec is. I have a hard time > > instantiating it, and I suspect it is useless in the main > application, > > firewall and nat traversal. > > Examples: "Let the packet through" (that's your standard firewall > pinhole). "Translate the source address/port to 192.69.1.201/42". > "Encapsulate in XML and divert to that OPES service over there" (oops, > did I say that?). This is not unusual stuff. Think in terms of sed. Actually, I would rather think in term of discrete attributes than text editor's commands. "Let the packet through" can just as well be represented by a "status" attribute with values such as closed, sendonly, recvonly, open. "Translate" can only be an attribute if the firewall is implementing a NAT function, and in that case it is pretty much equivalent to "let the packet through" -- there is no other way. Then, you get attributes, such as the address mapping or the port mapping; these attributes are typically present in the commands' responses, "you will be mapped to 192.69.1.201:42", and are typically optional in the request "I would like port 80." -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 16:06: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 ESMTP id QAA29503 for ; Mon, 10 Sep 2001 16:06: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 PAA16727; Mon, 10 Sep 2001 15:59: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 PAA16696 for ; Mon, 10 Sep 2001 15:59:37 -0400 (EDT) Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29248 for ; Mon, 10 Sep 2001 15:58:07 -0400 (EDT) Received: from 157.54.9.108 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 Sep 2001 12:57:29 -0700 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, 10 Sep 2001 12:57:24 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Sep 2001 12:57:22 -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, 10 Sep 2001 12:56:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Terminology discussion - status Date: Mon, 10 Sep 2001 12:56:48 -0700 Message-ID: Thread-Topic: [midcom] Terminology discussion - status Thread-Index: AcE6KM+c3pIKKtVnQrGPzgWZ3+4MdwACc8GA From: "Christian Huitema" To: "Melinda Shore" , X-OriginalArrivalTime: 10 Sep 2001 19:56:49.0051 (UTC) FILETIME=[BA3E5EB0:01C13A32] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA16697 Sender: 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 > >Frankly, I don't know what the action spec is. I have a hard time > >instantiating it, and I suspect it is useless in the main > application, > >firewall and nat traversal. > > An action spec is a "command" (install, delete, modify, etc.). > I still don't like this approach, but there has been some feeling > for having commands as parameters rather than as, uh, commands. Then, I like it even less. The command is there to affect the set of "rulesets" that are present in the firewall; the command itself cannot an attribute of the ruleset. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 17:07:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01728 for ; Mon, 10 Sep 2001 17:07: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 RAA19250; Mon, 10 Sep 2001 17:03: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 RAA19219 for ; Mon, 10 Sep 2001 17:03:05 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01574 for ; Mon, 10 Sep 2001 17:01:35 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AA848E20142; Mon, 10 Sep 2001 17:03:00 -0400 Message-ID: <002b01c13a3b$bf19b8e0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Christian Huitema" , , "Melinda Shore" References: <5.1.0.14.0.20010910143656.00a68160@mira-sjc5-4.cisco.com> Subject: Re: [midcom] Terminology discussion - status Date: Mon, 10 Sep 2001 17:01:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit What is wrong with commands? (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Melinda Shore" To: "Christian Huitema" ; Sent: Monday, September 10, 2001 2:43 PM Subject: RE: [midcom] Terminology discussion - status > At 11:29 AM 9/10/01 -0700, Christian Huitema wrote: > >Frankly, I don't know what the action spec is. I have a hard time > >instantiating it, and I suspect it is useless in the main application, > >firewall and nat traversal. > > An action spec is a "command" (install, delete, modify, etc.). > I still don't like this approach, but there has been some feeling > for having commands as parameters rather than as, uh, commands. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 17:12: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 ESMTP id RAA01926 for ; Mon, 10 Sep 2001 17:12: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 RAA19438; Mon, 10 Sep 2001 17:09:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19405 for ; Mon, 10 Sep 2001 17:09:53 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01754 for ; Mon, 10 Sep 2001 17:08:23 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AC18123F0142; Mon, 10 Sep 2001 17:09:44 -0400 Message-ID: <004901c13a3c$af1ac320$2300000a@acmepacket.com> From: "Bob Penfield" To: "Bob Penfield" , "Christian Huitema" , , "Melinda Shore" References: <5.1.0.14.0.20010910143656.00a68160@mira-sjc5-4.cisco.com> <002b01c13a3b$bf19b8e0$2300000a@acmepacket.com> Subject: Re: [midcom] Terminology discussion - status Date: Mon, 10 Sep 2001 17:08:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.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 never mind. I agree with Mark & Christian. The "actions" are not commands. Commands are the things in the protocol that manipulate rulesets. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Bob Penfield" To: "Christian Huitema" ; ; "Melinda Shore" Sent: Monday, September 10, 2001 5:01 PM Subject: Re: [midcom] Terminology discussion - status > What is wrong with commands? > > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Melinda Shore" > To: "Christian Huitema" ; > Sent: Monday, September 10, 2001 2:43 PM > Subject: RE: [midcom] Terminology discussion - status > > > > At 11:29 AM 9/10/01 -0700, Christian Huitema wrote: > > >Frankly, I don't know what the action spec is. I have a hard time > > >instantiating it, and I suspect it is useless in the main application, > > >firewall and nat traversal. > > > > An action spec is a "command" (install, delete, modify, etc.). > > I still don't like this approach, but there has been some feeling > > for having commands as parameters rather than as, uh, commands. > > > > Melinda > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www1.ietf.org/mailman/listinfo/midcom > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 17:34:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02479 for ; Mon, 10 Sep 2001 17:34: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 RAA20191; Mon, 10 Sep 2001 17:35: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 RAA20158 for ; Mon, 10 Sep 2001 17:35:03 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02459 for ; Mon, 10 Sep 2001 17:33:32 -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 f8ALYVx29703 for ; Mon, 10 Sep 2001 14:34:31 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-25.cisco.com [10.21.96.25]) by airborne.cisco.com (Mirapoint) with SMTP id AAW21005; Mon, 10 Sep 2001 14:34:29 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 10 Sep 2001 17:34:34 -0400 Date: Mon, 10 Sep 2001 17:34:34 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Terminology discussion - status Message-ID: <20010910173433.M1376@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <5.1.0.14.0.20010910143656.00a68160@mira-sjc5-4.cisco.com> <002b01c13a3b$bf19b8e0$2300000a@acmepacket.com> <004901c13a3c$af1ac320$2300000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <004901c13a3c$af1ac320$2300000a@acmepacket.com>; from bpenfield@acmepacket.com on Mon, Sep 10, 2001 at 05:08:05PM -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, Sep 10, 2001 05:08:05PM -0400, Bob Penfield allegedly wrote: > never mind. I agree with Mark & Christian. The "actions" are not commands. > Commands are the things in the protocol that manipulate rulesets. I sense confusion in the group. You're talking about the protocol. Right. The protocol contains various predicates including sets of rules the sender wishes to see installed. At that point the rulesets are not "commands". However, other people are talking about "actions" in the middlebox. Once a ruleset is installed in the middlebox, the middlebox may represent it any way it likes, but for every packet which the filtering selects, some kind of action is performed (it might be a "null" action, i.e. a drop). If "action" is causing this much trouble, let's go back to Dave Oran's formulation: a ruleset has one or more "matching rules" and one or more "transform rules". That would satisfy me. It might be my fault that we moved away from it in the beginning because I was trying to use simple terms. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 10 18:29: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 ESMTP id SAA03882 for ; Mon, 10 Sep 2001 18:29: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 SAA21368; Mon, 10 Sep 2001 18:25: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 SAA21338 for ; Mon, 10 Sep 2001 18:25: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 ESMTP id SAA03809 for ; Mon, 10 Sep 2001 18:24:28 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q131AVW9; Mon, 10 Sep 2001 18:25:27 -0400 Message-Id: <3.0.5.32.20010910182439.00a2fc50@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 10 Sep 2001 18:24:39 -0400 To: midcom@ietf.org From: Mark Duffy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Terminology discussion - regroup Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org OK, lots of emails today on this. Here is an updated proposal in which I have attempted to incorporate the results of the discussion. (Noting that there have been assorted opinions expressed and this certainly doesn't satisfy everything that everyone asked for.) I got rid of the word "action". Classifier Rule Packet matching information that identifies a set of packets to be treated a certain way by a middlebox. [[Note: I tried "Matching Rule" here but felt it would create ambiguities in some contexts where it could be confused with "a rule that does match".]] Disposition Rule Description of the middlebox treatment/service to be applied to a set of packets. Ruleset The combination of one or more classifier rules and one or more disposition rules. Packets matching the classifier rule(s) are to be treated as specified by the associated disposition rules(s). The ruleset may also contain auxiliary attributes such as ruleset type, timeout values, creating agent, etc. Pinhole -- eliminate this term if possible. Else: A behavior of a firewall-type middlebox to allow a specified set of packets to traverse the middlebox. Pinholes instigated via the midcom protocol are described by Rulesets. Pinhole-descriptor -- replace uses of this term with "ruleset". Flow -- Resource -- Do not define these in the terminology section. Use them as general english words as needed in the text. Connection -- eliminate use of this word to refer to the association between midcom agent and middlebox. Instead use the term Midcom Session as recently proposed. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 11 09: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 ESMTP id JAA07070 for ; Tue, 11 Sep 2001 09: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 JAA17738; Tue, 11 Sep 2001 09:15: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 JAA17707 for ; Tue, 11 Sep 2001 09:15:35 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06895 for ; Tue, 11 Sep 2001 09:15: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 f8BDFNv07828; Tue, 11 Sep 2001 06:15:23 -0700 (PDT) Received: from spandex.cisco.com (sjc-vpn-261.cisco.com [10.21.65.5]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACY01612; Tue, 11 Sep 2001 06:15:00 -0700 (PDT) Message-Id: <5.1.0.14.0.20010911091605.00a7ab30@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Sep 2001 09:16:46 -0400 To: Mark Duffy , midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Terminology discussion - regroup In-Reply-To: <3.0.5.32.20010910182439.00a2fc50@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Let's focus on getting this resolved in the next few days. Are there objections to anything in this proposal? Melinda At 06:24 PM 9/10/01 -0400, Mark Duffy wrote: >OK, lots of emails today on this. >Here is an updated proposal in which I have attempted to incorporate the >results of the discussion. (Noting that there have been assorted opinions >expressed and this certainly doesn't satisfy everything that everyone asked >for.) I got rid of the word "action". > > >Classifier Rule > Packet matching information that identifies a set of packets to be >treated a certain way by a middlebox. [[Note: I tried "Matching Rule" >here but felt it would create ambiguities in some contexts where it could >be confused with "a rule that does match".]] > >Disposition Rule > Description of the middlebox treatment/service to be applied to a set >of packets. > >Ruleset > The combination of one or more classifier rules and one or more >disposition rules. Packets matching the classifier rule(s) are to be >treated as specified >by the associated disposition rules(s). The ruleset may also contain >auxiliary attributes such as ruleset type, timeout values, creating agent, >etc. > > >Pinhole -- eliminate this term if possible. Else: > A behavior of a firewall-type middlebox to allow a specified set of >packets to traverse the middlebox. Pinholes instigated via the midcom >protocol are described by Rulesets. > >Pinhole-descriptor -- replace uses of this term with "ruleset". > >Flow -- >Resource -- > Do not define these in the terminology section. Use them as general >english words as needed in the text. > >Connection -- eliminate use of this word to refer to the association >between midcom agent and middlebox. Instead use the term Midcom Session as >recently proposed. > > > >_______________________________________________ >midcom mailing list >midcom@ietf.org >http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 11 10:18:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09037 for ; Tue, 11 Sep 2001 10:18: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 KAA19458; Tue, 11 Sep 2001 10:10: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 KAA19431 for ; Tue, 11 Sep 2001 10:10:56 -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 KAA08909 for ; Tue, 11 Sep 2001 10:10:50 -0400 (EDT) Message-ID: <20010911141053.93368.qmail@web13807.mail.yahoo.com> Received: from [65.12.33.187] by web13807.mail.yahoo.com via HTTP; Tue, 11 Sep 2001 07:10:53 PDT Date: Tue, 11 Sep 2001 07:10:53 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Terminology discussion - regroup To: Mark Duffy , midcom@ietf.org In-Reply-To: <3.0.5.32.20010910182439.00a2fc50@email.quarrytech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --- Mark Duffy wrote: > OK, lots of emails today on this. > Here is an updated proposal in which I have attempted to incorporate the > results of the discussion. (Noting that there have been assorted opinions > expressed and this certainly doesn't satisfy everything that everyone asked > for.) I got rid of the word "action". > Thanks, Mark, for summarizing. > > Classifier Rule > Packet matching information that identifies a set of packets to be > treated a certain way by a middlebox. [[Note: I tried "Matching Rule" > here but felt it would create ambiguities in some contexts where it could > be confused with "a rule that does match".]] I suspect, you are trying to name the packets that are subject to middlebox scrutiny (e.g., those that are dropped by firewall, those that are translated by NAT). Firewall finds these using a matching classifier rule-set. NAT finds these by matching the src/dest address (and port) against the configured address maps. I am not certain there is a good term for describing this. If we have to name one, I would prefer if this were renamed, "Middlebox classifier rule". > > Disposition Rule > Description of the middlebox treatment/service to be applied to a set > of packets. > I would prefer if this were renamed "Middlebox-Disposition". Disposition is not a rule. Disposition is a process or a function or an action. Middlebox disposition is a middlebox-function specific treatment on the packet. > Ruleset > The combination of one or more classifier rules and one or more > disposition rules. Packets matching the classifier rule(s) are to be > treated as specified > by the associated disposition rules(s). The ruleset may also contain > auxiliary attributes such as ruleset type, timeout values, creating agent, > etc. > Now, this gets a bit murky. Here we are trying to describe parameters that guide the middlebox function. Why dont we call them simply as "Middlebox configuration parameters"? The config will include middlebox function specific parameters - such as firewall ACLs, NAT address maps, timeouts etc. This cannot simply be a set of rule oriented tuples such as (Middlebox-classifier-rule, Middlebox-disposition-funtion). The tuples are just one of the config parameters. > > Pinhole -- eliminate this term if possible. Else: > A behavior of a firewall-type middlebox to allow a specified set of > packets to traverse the middlebox. Pinholes instigated via the midcom > protocol are described by Rulesets. > This is a firewall specific middlebox-classifier rule. > Pinhole-descriptor -- replace uses of this term with "ruleset". Suggest droping the term. A firewall may be described by a list of pinholes and the associated dispositions. > > Flow -- > Resource -- > Do not define these in the terminology section. Use them as general > english words as needed in the text. > Agreed. > Connection -- eliminate use of this word to refer to the association > between midcom agent and middlebox. Instead use the term Midcom Session as > recently proposed. OK regards, suresh ===== __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 11 18:34: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 ESMTP id SAA20121 for ; Tue, 11 Sep 2001 18:34: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 SAA00291; Tue, 11 Sep 2001 18:26: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 SAA00257 for ; Tue, 11 Sep 2001 18:26: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 ESMTP id SAA19970 for ; Tue, 11 Sep 2001 18:26:20 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SXH3LJJ8; Tue, 11 Sep 2001 18:25:53 -0400 Message-Id: <3.0.5.32.20010911182502.00a22390@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 11 Sep 2001 18:25:02 -0400 To: Pyda Srisuresh , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Terminology discussion - regroup In-Reply-To: <20010911141053.93368.qmail@web13807.mail.yahoo.com> References: <3.0.5.32.20010910182439.00a2fc50@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi Suresh, see comments added below... -Mark >> Classifier Rule >> Packet matching information that identifies a set of packets to be >> treated a certain way by a middlebox. [[Note: I tried "Matching Rule" >> here but felt it would create ambiguities in some contexts where it could >> be confused with "a rule that does match".]] > >I suspect, you are trying to name the packets that are subject to >middlebox scrutiny (e.g., those that are dropped by firewall, those >that are translated by NAT). Firewall finds these using a matching >classifier rule-set. NAT finds these by matching the src/dest address >(and port) against the configured address maps. > >I am not certain there is a good term for describing this. If we have >to name one, I would prefer if this were renamed, "Middlebox classifier >rule". A little longer and hence less convenient than just "classifier rule" but if folks prefer this I don't object. >> Disposition Rule >> Description of the middlebox treatment/service to be applied to a set >> of packets. >> > >I would prefer if this were renamed "Middlebox-Disposition". >Disposition is not a rule. Disposition is a process or a function or >an action. > >Middlebox disposition is a middlebox-function specific treatment on >the packet. "Middlebox disposition" suggests to me that it refers to what happened to a particular middlebox. E.g.: Jim "What was the disposition of that middlebox?" Mary: "I unplugged it and put it in the rubbish" "Packet Disposition" would be a bit better. My personal preference is still for "Disposition Rule" but if folks prefer this I don't object. >> Ruleset >> The combination of one or more classifier rules and one or more >> disposition rules. Packets matching the classifier rule(s) are to be >> treated as specified >> by the associated disposition rules(s). The ruleset may also contain >> auxiliary attributes such as ruleset type, timeout values, creating agent, >> etc. >> > >Now, this gets a bit murky. > >Here we are trying to describe parameters that guide the middlebox >function. Why dont we call them simply as "Middlebox configuration >parameters"? The config will include middlebox function specific >parameters - such as firewall ACLs, NAT address maps, timeouts etc. >This cannot simply be a set of rule oriented tuples such as >(Middlebox-classifier-rule, Middlebox-disposition-funtion). The tuples >are just one of the config parameters. I actively disgree with you on that. In my mind middlebox configuration parameters are information put in the middlebox typically by a human operator. Things like its interfaces, its IP addresses, how to do logging, policy, etc. etc. The Rulesets are somewhat more dynamic and from midcom perstective will be put in the middlbox by a midcom agent. I would daresay that many middleboxes may support access to similar functionality via configuaration as via midcom. I.e. a firewall might allow traversal of a set of packets because it was so directed by its configuration, or because it was so directed by a midcom agent. But I don't believe that what the midcom agent sends to the middlebox should be called "configuration". >> Pinhole -- eliminate this term if possible. Else: >> A behavior of a firewall-type middlebox to allow a specified set of >> packets to traverse the middlebox. Pinholes instigated via the midcom >> protocol are described by Rulesets. >> > >This is a firewall specific middlebox-classifier rule. In my mind "pinhole" is not a "middlebox-classifier rule" aka "classifier rule". Rather, it is a thing/behavior manifested by a firewall middlebox as a result of being told to install a ruleset. Of course, if we can just eliminate this term that would be easiest all around! >> Pinhole-descriptor -- replace uses of this term with "ruleset". > >Suggest droping the term. >A firewall may be described by a list of pinholes and the associated >dispositions. > >> >> Flow -- >> Resource -- >> Do not define these in the terminology section. Use them as general >> english words as needed in the text. >> >Agreed. > >> Connection -- eliminate use of this word to refer to the association >> between midcom agent and middlebox. Instead use the term Midcom Session as >> recently proposed. > >OK > >regards, >suresh _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 12 14:18:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29536 for ; Wed, 12 Sep 2001 14:18:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04511; Wed, 12 Sep 2001 14:04: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 OAA04480 for ; Wed, 12 Sep 2001 14:04:42 -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 OAA29284 for ; Wed, 12 Sep 2001 14:04:13 -0400 (EDT) Message-ID: <20010912180415.37727.qmail@web13802.mail.yahoo.com> Received: from [66.89.112.150] by web13802.mail.yahoo.com via HTTP; Wed, 12 Sep 2001 11:04:15 PDT Date: Wed, 12 Sep 2001 11:04:15 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Terminology discussion - regroup To: Mark Duffy , Pyda Srisuresh , midcom@ietf.org In-Reply-To: <3.0.5.32.20010911182502.00a22390@email.quarrytech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --- Mark Duffy wrote: > Hi Suresh, see comments added below... -Mark > <... stuff deleted> > > > >> Disposition Rule > >> Description of the middlebox treatment/service to be applied to a set > >> of packets. > >> > > > >I would prefer if this were renamed "Middlebox-Disposition". > >Disposition is not a rule. Disposition is a process or a function or > >an action. > > > >Middlebox disposition is a middlebox-function specific treatment on > >the packet. > > "Middlebox disposition" suggests to me that it refers to what happened to a > particular middlebox. E.g.: > Jim "What was the disposition of that middlebox?" > Mary: "I unplugged it and put it in the rubbish" > "Packet Disposition" would be a bit better. My personal preference is > still for "Disposition Rule" but if folks prefer this I don't object. Hmm.. The usage above doesnt fit the definition. Middlebox disposition is a middlebox-function specific treament on a packet (not the box). If you prefer, we can go with "Middlebox packet disposition" . But, I am Ok with simple "Middlebox disposition". > > >> Ruleset > >> The combination of one or more classifier rules and one or more > >> disposition rules. Packets matching the classifier rule(s) are to be > >> treated as specified > >> by the associated disposition rules(s). The ruleset may also contain > >> auxiliary attributes such as ruleset type, timeout values, creating agent, > >> etc. > >> > > > >Now, this gets a bit murky. > > > >Here we are trying to describe parameters that guide the middlebox > >function. Why dont we call them simply as "Middlebox configuration > >parameters"? The config will include middlebox function specific > >parameters - such as firewall ACLs, NAT address maps, timeouts etc. > >This cannot simply be a set of rule oriented tuples such as > >(Middlebox-classifier-rule, Middlebox-disposition-funtion). The tuples > >are just one of the config parameters. > > I actively disgree with you on that. In my mind middlebox configuration > parameters are information put in the middlebox typically by a human > operator. Things like its interfaces, its IP addresses, how to do logging, > policy, etc. etc. Also included are the middlebox function specific parameters - I.e., the firewall ACLs, NAT address maps, timers etc. The agent will likely query the middlebox for these parameters. > > The Rulesets are somewhat more dynamic and from midcom perstective will be > put in the middlbox by a midcom agent. The ruleset may be dynamically changing in the sense that newer resource allocation/deallocations are signalled by the agent. But, the agent is not the sole owner of these parameters. Midcom is an extension to the basic middlebox operation. Not a fork-lift in the way it is configured and operates. > > I would daresay that many middleboxes may support access to similar > functionality via configuaration as via midcom. I.e. a firewall might > allow traversal of a set of packets because it was so directed by its > configuration, or because it was so directed by a midcom agent. But I > don't believe that what the midcom agent sends to the middlebox should be ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > called "configuration". In that case, you are merely refering to the Midcom-agent signalled resources/parameters - not the whole ruleset and other middlebox parameters. Midcom agent may have no control over some of the basic rules, such as NAT address maps, and default TCP/UDP session timers. Midcom agent may be allowed to make individual session specific paramter changes, not the middlebox function configuration as a whole. > > > >> Pinhole -- eliminate this term if possible. Else: > >> A behavior of a firewall-type middlebox to allow a specified set of > >> packets to traverse the middlebox. Pinholes instigated via the midcom > >> protocol are described by Rulesets. > >> > > > >This is a firewall specific middlebox-classifier rule. > > In my mind "pinhole" is not a "middlebox-classifier rule" aka "classifier > rule". Rather, it is a thing/behavior manifested by a firewall middlebox > as a result of being told to install a ruleset. Of course, if we can just > eliminate this term that would be easiest all around! Hmm.. sounds very confusing. Is it permit on a pinhole (or) deny on a pinhole you are refering to as the bahaviour manifested. I have no issues with dropping the term. <... stuff deleted> regards, suresh __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 12:48:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08666 for ; Thu, 13 Sep 2001 12:48: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 MAA17496; Thu, 13 Sep 2001 12:41: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 MAA17467 for ; Thu, 13 Sep 2001 12:41:55 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08446 for ; Thu, 13 Sep 2001 12:41:48 -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 f8DGfFv00365 for ; Thu, 13 Sep 2001 09:41:15 -0700 (PDT) Received: from SBRIM-W2K (rtp-vpn1-55.cisco.com [10.82.224.55]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ13904; Thu, 13 Sep 2001 09:40:52 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 13 Sep 2001 12:40:51 -0400 Date: Thu, 13 Sep 2001 12:40:50 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Topology considerations documents Message-ID: <20010913124050.K1636@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 huitema@windows.microsoft.com on Thu, Sep 06, 2001 at 04:03:49PM -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, Sep 06, 2001 04:03:49PM -0700, Christian Huitema allegedly wrote: > I have read all three drafts, and have these feelings that we are well > on our way to define a camel... Yup > I would like a different analysis, > starting with the simplest topology and extending to the more complex > topologies envisaged in the draft. Yup > I guess we all agree that the simplest topology is that of the "basic > firewall" configuration: a protected domain that we can call "the > interior", and by opposition a non protected side that we can call "the > exterior". The concept of interior and exterior leads us in this case to > a very simple pinhole specification. The pinhole is identified by: Except you assume that the agent knows a particular address [range] is inside or outside. How can it know that? It looks like you're assuming this "realm" infrastructure and administration is in place. In the case of wildcards an agent does need to let the middlebox know if it's talking about a rule for inside or outside addresses, but it can't know if a specific address is inside or outside. > Indeed, each of these values can be wildcarded, or maybe replaced by a > "prefix" in the case of addresses. The pinhole will then have > attributes, such as: > Direction: send, recv, sendrecv, closed I think this is a much less significant point, but for now I would like to keep this simple. First, take out "closed" -- if a rule doesn't exist it's closed. Second, "send" and "receive" are useful only if you use inside/outside as your primary descriptor, and I don't think you can (see above). Finally, it's easy enough to have two one-way rulesets that I would like to leave out the sendrecv option, for robustness. > Mapping of the interior address to the outside, if NAT > Maybe mapping of the exterior address on the inside > Etc. > A very good outcome of the directionality, i.e. from the inside out, is > that we can order the list of pinholes, as if the 5 tuple was one big > number. This allows us to define unambiguously which pinhole is most > specifically matching a given packet header -- i.e., in the matching > list, the one that comes first in the ordering, assuming that wildcards > rank after specified values. I don't see how that's different from any other rigid ordering. Suppose we rigidly specified srcaddr, srcport, dstaddr, dstport, proto -- with the same rules? What's different? > OK, so we have a cool simple solution for the simple case, so what about > the complex case, for example the case quoted in > draft-penfield-midcom-realms-00.txt in which a single box protects > several networks: > > > +-------------+ > | | +------+ > | Customer A | | | +---------------+ > | +-----------+ | | | > | 10.0.0.x | | | | | > | | | | | Service | > +-------------+ |Middle| | Provider | > | Box +------+ | > +-------------+ | | | | > | | | | | 192.168.20.x | > | Customer B | | | | | > | +-----------+ | +---------------+ > | 10.0.0.x | | | > | | +------+ > +-------------+ > > Well, we may observe that such constructs are by and large equivalent to > a multiple-box construct: > > +-------------+ > | | +------+ > | Customer A | | | +---------------+ > | +-----------+ MB-A | | | > | 10.0.0.x | | | | | > | | +......+ | Service | > +-------------+ . . | Provider | > . +------+ | > +-------------+ . . | | > | | +......+ | 192.168.20.x | > | Customer B | | | | | > | +-----------+ MB-B | +---------------+ > | 10.0.0.x | | | > | | +------+ > +-------------+ In the current case, yes. > We don't want to split the hardware, but nothing prevents us from > adopting a logical view in which "MB-A" and "MB-B" are different "midcom > servers", i.e. have different logical names. So, if an agent wants to > open a port for A, it sends comment to the midcom server "MB-A", and to > "MB-B" if it wants to open a port for B. Pretty soon, we have a generic > mechanism with a clear naming rule -- a name associated with the > protected domain -- and a simple semantic -- interior and exterior. How does the agent know which virtual middlebox connects to which network? This is a discovery problem, but you seem to imply that the agent somehow gets "realm" topology information. > Looks nice, uh? Modulo all the problems :) _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 13:21:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10088 for ; Thu, 13 Sep 2001 13:21: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 NAA18648; Thu, 13 Sep 2001 13:13: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 NAA18615 for ; Thu, 13 Sep 2001 13:13:39 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09686 for ; Thu, 13 Sep 2001 13:13:32 -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 f8DHCwv26037 for ; Thu, 13 Sep 2001 10:12:59 -0700 (PDT) Received: from SBRIM-W2K (rtp-vpn1-55.cisco.com [10.82.224.55]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ14595; Thu, 13 Sep 2001 10:12:35 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 13 Sep 2001 13:12:34 -0400 Date: Thu, 13 Sep 2001 13:12:34 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Topology considerations documents Message-ID: <20010913131234.P1636@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <3.0.5.32.20010906171650.00a1d860@email.quarrytech.com> <008101c136d2$26055400$2300000a@acmepacket.com> <20010906133030.A1764@SBRIM-W2K> <007401c13702$d7b96bc0$2300000a@acmepacket.com> <3.0.5.32.20010906171650.00a1d860@email.quarrytech.com> <20010906174505.E1436@SBRIM-W2K> <3.0.5.32.20010906184545.009d9a00@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.20010906184545.009d9a00@email.quarrytech.com>; from mduffy@quarrytech.com on Thu, Sep 06, 2001 at 06:45:45PM -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Thu, Sep 06, 2001 06:45:45PM -0400, Mark Duffy allegedly wrote: > Hi Scott, see comments interspersed below... > > At 05:45 PM 9/6/01 -0400, Scott Brim wrote: > >On Thu, Sep 06, 2001 05:16:50PM -0400, Mark Duffy allegedly wrote: > >> My understanding is similar to what Bob has stated. The realm identifiers > >> only need to be unique within the middlebox that the midcom request is > >> directed to. The point of all the gladiators' drafts is (I think) that > >> the agent must know which middlebox it needs to send a particular request > >> to, and must know which of the realms connected to that middlebox to tell > >> the middlebox each pinhole/etc. request relates to. > > > >How will a particular agent find out what realm identifiers a middlebox > >is using to name its attached realms, > > MD-> I don't know for sure. Probably by configuration. The question > doesn't bother me too much because I think the *same* question would need > to be asked if using interface identifiers rather than realm identifiers. > I.e. How does the agent know how the middlebox names its interfaces, and > which ones are connected to where? That's not the point I was making. Interface IDs and realm IDs are equally ugly. At least with interface identifiers it's a purely local problem. If you try to use a realm abstraction, it quickly becomes a non-local problem. I can go through that again if you like. > > and whether those realms are > >inside or outside the trust/addressing boundaries? Configuration? > > MD-> Again, the agent needs to know whether the 'sides' of the middlebox > are in/out of a given trust boundary, whether those 'sides' are denominated > as "interfaces" or "realms". And the agent needs to communicate that to > the middlebox through midcom. No. The agent does not need to know those things, as long as the middlebox knows them. The agent can (as we proposed in our draft) tell the middlebox a couple details and let the middlebox use its intelligence to make the decision. The middlebox is in the topologically appropriate place to make the decision, while an agent is potentially nowhere near it. In order for the agent to have this kind of intelligence you need to add complexity to support it. > It's just a matter of the granularity with > which the world is broken into realms by the middlebox. I don't think the > agent should care what that granularity is, other than using the > appropriate syntax to name the realms over the wire in the midcom protocol. > > >Again you have management problems and potential security problems (as > >already discussed -- I'd rather not repeat it). Remember there are > >users out there, and we must not, in any way, insist on their getting > >configuration right. How about ... a global namespace and modification > >of all application signaling? > > MD-> Obviously, global namespace and modification of all application > signaling is out of the question. I do think the agent needs to know the > names of *something* (interfaces/realms/sides/domains/whatever) that the > middlebox works against, and be able to specify them to the middlebox. I'm > just trying to prevent midcom from embodying an assumption that for all > middleboxes, domain==interface. Our draft is about the agent only needing to know just what it already knows from the existing Internet infrastructure -- IP addresses for whatever it is already communicating with. It does not need to know any names of any new abstractions, nor does it need to know the details of configuration of the middlebox. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 13:21:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10099 for ; Thu, 13 Sep 2001 13:21:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18691; Thu, 13 Sep 2001 13:13: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 NAA18662 for ; Thu, 13 Sep 2001 13:13: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 ESMTP id NAA09707 for ; Thu, 13 Sep 2001 13:13:45 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f8DHCtx18757 for ; Thu, 13 Sep 2001 10:12:55 -0700 (PDT) Received: from SBRIM-W2K (rtp-vpn1-55.cisco.com [10.82.224.55]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ14599; Thu, 13 Sep 2001 10:12:48 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 13 Sep 2001 13:12:47 -0400 Date: Thu, 13 Sep 2001 13:12:46 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Topology considerations documents Message-ID: <20010913131246.Q1636@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <20010906175224.F1436@SBRIM-W2K> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from amolitor@visi.com on Thu, Sep 06, 2001 at 05:04:53PM -0500 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Thu, Sep 06, 2001 05:04:53PM -0500, Andrew Molitor allegedly wrote: > On Thu, 6 Sep 2001, Scott Brim wrote: > > > Right, I saw that you said that. So, how does the agent classify an > > interaction into a realm? Well, I hesitate to repeat what I sent before > > but I don't see any scalable *and* manageable way to do it. I'll repeat > > myself tomorrow :-). > > Oh, I concur completely. This is a hard problem to solve. > > Luckily, it's totally out of scope for MIDCOM so we don't > have to worry about it, at least not directly. At any rate, this > is how I see the scope. I certainly remember nothing about being > chartered to invent either a global realm namespace or a (local) > realm naming convention. You cannot propose a solution in a vacuum. You have to consider the implications. We've said, for example, that middleboxes that divert packets are out of scope, but we are not simultaneously requiring the existence of such things. The midcom requirements so far have very clean, limited implications for the rest of the world. They don't assume any kind of infrastructure we don't already have. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 13:22:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10119 for ; Thu, 13 Sep 2001 13:22: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 NAA18543; Thu, 13 Sep 2001 13:09: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 NAA18510 for ; Thu, 13 Sep 2001 13:09:27 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09501 for ; Thu, 13 Sep 2001 13:09:20 -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 f8DH8lv22727 for ; Thu, 13 Sep 2001 10:08:47 -0700 (PDT) Received: from SBRIM-W2K (rtp-vpn1-55.cisco.com [10.82.224.55]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ14476; Thu, 13 Sep 2001 10:08:22 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 13 Sep 2001 13:08:22 -0400 Date: Thu, 13 Sep 2001 13:08:22 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Topology considerations documents Message-ID: <20010913130822.O1636@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 jlacour@netscreen.com on Thu, Sep 06, 2001 at 04:18:11PM -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, Sep 06, 2001 04:18:11PM -0700, John LaCour allegedly wrote: > I just want a way in MIDCOM to specify MB-A or MB-B so that I can > avoid having multiple MIDCOM servers on my middlebox and avoid duplicating > authentication mechanisms whenever I have one middlebox agent talking > to both MB-A and MB-B. I've rarely seen a case where virtualization of a device was known, and taken account of, in the protocol to control that device. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 13:30:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10418 for ; Thu, 13 Sep 2001 13:30: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 NAA18937; Thu, 13 Sep 2001 13:24: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 NAA18905 for ; Thu, 13 Sep 2001 13:24: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 ESMTP id NAA10202 for ; Thu, 13 Sep 2001 13:24:45 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f8DHNpx28098 for ; Thu, 13 Sep 2001 10:23:51 -0700 (PDT) Received: from SBRIM-W2K (rtp-vpn1-55.cisco.com [10.82.224.55]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ14879; Thu, 13 Sep 2001 10:23:49 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 13 Sep 2001 13:23:49 -0400 Date: Thu, 13 Sep 2001 13:23:48 -0400 From: Scott Brim To: midcom mail-list Subject: Re: [midcom] Topology considerations documents Message-ID: <20010913132348.S1636@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom mail-list References: <00ef01c137a5$bc3b02c0$2300000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00ef01c137a5$bc3b02c0$2300000a@acmepacket.com>; from bpenfield@acmepacket.com on Fri, Sep 07, 2001 at 10:02:30AM -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 Fri, Sep 07, 2001 10:02:30AM -0400, Bob Penfield allegedly wrote: > OK, let's try an example. > > +---------+ MB > | Realm A +---\ +---+ +----------+ > +---------+ +---+ VLAN1 | (2)----+ | > |L2X+========(1) | WAN | Realm SP | > +---------+ +---+ VLAN2 | (3)----+ | > | Realm B +---/ +---+ +----------+ > +---------+ > > Here's a middlebox connected to 3 networks (realms). It has 3 physical > interface (1), (2), and (3). Realms A and B are connected to a Layer 2 > switch (L2X) which aggregates/multiplexes the 2 LANs over a single ethernet > connection to (1) using VLAN tags. Interfaces (2) and (3) both connect to > the SP network for redundancy. There are 3 "logical" interfaces: VLAN1 and > VLAN2 on physical interface (1) and WAN on physical interfaces (2)&(3). > These logical interfaces are equivalent to the realm they connect to. The > realm is at the other end of the logical pipe. Thus VLAN1=Realm A, > VLAN2=Realm B, and WAN=Realm SP. > > I basically agree with Andrew that what were are trying to communicate to > the middlebox is which interfaces the flow goes in/out of the middlebox. > What I'm trying to illustrate above is that it is not physical interface, > but logical interface that needs to be communicated in MIDCOM. Now if we > want to call this logical interface (or even interface for short), that's > fine with me. > > The middlebox owns the namespace for these logical interfaces. There is no > need for a global or universal namespace. Only the midcom agents that talk > to the middlebox need to be aware of the names/identifiers to use. Agents > that need to differentiate the identifiers of multiple middleboxes COULD use > the IP address or FQDN of the middlebox. OK, so the middlebox that you are trying to control owns the naming of the realms it is attached to. - How is that naming communicated to agents so they know which realm they are in? What if it changes? - Since not all application proxies will be agents, how does an existing application proxy find out the naming, so that it can know which realm it is in and communicate it to your agent+proxy? What if it changes? Note you need a scheme that works for all current and future application proxies that do session control, not just SIP. - If you have more than one middlebox connecting two realms, how do you get them to agree on the naming? If they don't, then how does an application proxy know which naming scheme to use when talking to your agent? I'm not after nicely engineered solutions, but I want an existence proof that something robust, scalable, and securable is possible. The method Adina and I proposed requires none of this. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 13:58:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11408 for ; Thu, 13 Sep 2001 13:58: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 NAA20120; Thu, 13 Sep 2001 13:54: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 NAA20087 for ; Thu, 13 Sep 2001 13:54:06 -0400 (EDT) Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11191 for ; Thu, 13 Sep 2001 13:53:57 -0400 (EDT) Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Sep 2001 10:53:02 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Sep 2001 10:53:02 -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, 13 Sep 2001 10:53:01 -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, 13 Sep 2001 10:52:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Topology considerations documents Date: Thu, 13 Sep 2001 10:52:23 -0700 Message-ID: Thread-Topic: [midcom] Topology considerations documents Thread-Index: AcE8dmJfa/HnFDYTSP+Q9r0UuI7sfwABUExg From: "Christian Huitema" To: "Scott Brim" , X-OriginalArrivalTime: 13 Sep 2001 17:52:24.0187 (UTC) FILETIME=[D813C4B0:01C13C7C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA20088 Sender: 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 > Except you assume that the agent knows a particular address [range] is > inside or outside. How can it know that? It looks like you're > assuming this "realm" infrastructure and administration is in place. In practical deployment, this is not a real problem. The requests will be issued either by the first party, which definitely knows that it is "inside" the firewalled area, or by a third party such as a SIP proxy, which also must have a reasonable knowledge of the topology -- otherwise it would not know which firewall to contact in the first place. > In the case of wildcards an agent does need to let the middlebox know > if it's talking about a rule for inside or outside addresses, but it > can't know if a specific address is inside or outside. I would assume that the firewall definitely must know whether a specific address is inside or outside. AFAIK, the firewall must have a rule for resolving addresses to interfaces; you went on to assume rules that are strictly based on addresses, which implicitly make the assumption that addresses can be related to sides. Note that we could conceive a double NAT scenario in which a rule strictly based on addresses would be ambiguous. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 13:59:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11447 for ; Thu, 13 Sep 2001 13:59:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20174; Thu, 13 Sep 2001 13: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 NAA20139 for ; Thu, 13 Sep 2001 13:54:45 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11217 for ; Thu, 13 Sep 2001 13:54:38 -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 f8DHrhP16499 for ; Thu, 13 Sep 2001 10:53:43 -0700 (PDT) Received: from SBRIM-W2K (rtp-vpn1-55.cisco.com [10.82.224.55]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ15588; Thu, 13 Sep 2001 10:53:43 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 13 Sep 2001 13:53:40 -0400 Date: Thu, 13 Sep 2001 13:53:40 -0400 From: Scott Brim To: midcom@ietf.org Message-ID: <20010913135339.U1636@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 huitema@windows.microsoft.com on Thu, Sep 13, 2001 at 10:43:30AM -0700 Subject: [midcom] Re: Need to close too (was: Topology considerations documents) Sender: 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, Sep 13, 2001 10:43:30AM -0700, Christian Huitema allegedly wrote: > > > Indeed, each of these values can be wildcarded, or maybe replaced by > > a > > > "prefix" in the case of addresses. The pinhole will then have > > > attributes, such as: > > > Direction: send, recv, sendrecv, closed > > > > I think this is a much less significant point, but for now I would > > like > > to keep this simple. First, take out "closed" -- if a rule doesn't > > exist it's closed... > > I actually insist on "closed." There are services such as intrusion > detection + repair that require closing traffic from a very specific > filter, even if there is a generic filter in place that would allow the > traffic to flow. Actually, we could make that a requirement, i.e. that > we can set up specific filters that are more restrictive than an > overlapping generic filter. I think the requirements bullets are open until the chair says otherwise. Could you give me specific text for R86 or whatever it is? ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 14:03: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 ESMTP id OAA11615 for ; Thu, 13 Sep 2001 14:03: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 NAA19762; Thu, 13 Sep 2001 13:45: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 NAA19729 for ; Thu, 13 Sep 2001 13:45:42 -0400 (EDT) Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10856 for ; Thu, 13 Sep 2001 13:45:29 -0400 (EDT) Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Sep 2001 10:44:13 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Sep 2001 10:44:08 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Sep 2001 10:44:07 -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); Thu, 13 Sep 2001 10:43:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Sep 2001 10:43:30 -0700 Message-ID: Thread-Topic: Need to close too (was: Topology considerations documents) Thread-Index: AcE8dmJfa/HnFDYTSP+Q9r0UuI7sfwABKSxg From: "Christian Huitema" To: "Scott Brim" , X-OriginalArrivalTime: 13 Sep 2001 17:43:30.0518 (UTC) FILETIME=[99FC5760:01C13C7B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA19731 Subject: [midcom] Need to close too (was: Topology considerations documents) Sender: 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 > > Indeed, each of these values can be wildcarded, or maybe replaced by > a > > "prefix" in the case of addresses. The pinhole will then have > > attributes, such as: > > Direction: send, recv, sendrecv, closed > > I think this is a much less significant point, but for now I would > like > to keep this simple. First, take out "closed" -- if a rule doesn't > exist it's closed... I actually insist on "closed." There are services such as intrusion detection + repair that require closing traffic from a very specific filter, even if there is a generic filter in place that would allow the traffic to flow. Actually, we could make that a requirement, i.e. that we can set up specific filters that are more restrictive than an overlapping generic filter. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 15:32: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 ESMTP id PAA13901 for ; Thu, 13 Sep 2001 15:32: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 PAA23128; Thu, 13 Sep 2001 15:17: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 PAA23103 for ; Thu, 13 Sep 2001 15:17:14 -0400 (EDT) Received: from inet-vrs-02.redmond.corp.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13581 for ; Thu, 13 Sep 2001 15:17:07 -0400 (EDT) Received: from 157.54.9.100 by inet-vrs-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Sep 2001 12:16:10 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Sep 2001 12:16:07 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Sep 2001 12:16:07 -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); Thu, 13 Sep 2001 12:15:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Re: Need to close too (was: Topology considerations documents) Date: Thu, 13 Sep 2001 12:15:29 -0700 Message-ID: Thread-Topic: [midcom] Re: Need to close too (was: Topology considerations documents) Thread-Index: AcE8fpFQbn/LoHwyTK67SG3lENsBWAACUvVA From: "Christian Huitema" To: "Scott Brim" , X-OriginalArrivalTime: 13 Sep 2001 19:15:29.0115 (UTC) FILETIME=[73536AB0:01C13C88] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA23104 Sender: 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 Proposed requirement R86 (or whatever is the number): R86: It should possible to define specific filters that are more restrictive than an overlapping generic filter, including filters that would prevent traffic for a specific set of IP addresses and transport parameters even if that traffic was authorized by an overlapping "wildcard" filter. Reasoning: this is required for rapid response to intrusion detection. -- Christian Huitema > -----Original Message----- > From: Scott Brim [mailto:swb@employees.org] > Sent: Thursday, September 13, 2001 10:54 AM > To: midcom@ietf.org > Subject: [midcom] Re: Need to close too (was: Topology considerations > documents) > > On Thu, Sep 13, 2001 10:43:30AM -0700, Christian Huitema allegedly > wrote: > > > > Indeed, each of these values can be wildcarded, or maybe > replaced by > > > a > > > > "prefix" in the case of addresses. The pinhole will then have > > > > attributes, such as: > > > > Direction: send, recv, sendrecv, closed > > > > > > I think this is a much less significant point, but for now I would > > > like > > > to keep this simple. First, take out "closed" -- if a rule > doesn't > > > exist it's closed... > > > > I actually insist on "closed." There are services such as intrusion > > detection + repair that require closing traffic from a very specific > > filter, even if there is a generic filter in place that would allow > the > > traffic to flow. Actually, we could make that a requirement, i.e. > that > > we can set up specific filters that are more restrictive than an > > overlapping generic filter. > > I think the requirements bullets are open until the chair says > otherwise. Could you give me specific text for R86 or whatever it is? > > ..Scott > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 15:48: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 ESMTP id PAA14269 for ; Thu, 13 Sep 2001 15:48: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 PAA23874; Thu, 13 Sep 2001 15:44: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 PAA23844 for ; Thu, 13 Sep 2001 15:44:14 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14148 for ; Thu, 13 Sep 2001 15:44:08 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SXH3LN1R; Thu, 13 Sep 2001 15:43:11 -0400 Message-Id: <3.0.5.32.20010913154221.009a39b0@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 13 Sep 2001 15:42:21 -0400 To: "Christian Huitema" , "Scott Brim" , From: Mark Duffy Subject: RE: [midcom] Re: Need to close too (was: Topology considerations documents) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:15 PM 9/13/01 -0700, Christian Huitema wrote: >Proposed requirement R86 (or whatever is the number): > >R86: It should possible to define specific filters that are more >restrictive than an overlapping generic filter, including filters that >would prevent traffic for a specific set of IP addresses and transport >parameters even if that traffic was authorized by an overlapping >"wildcard" filter. > >Reasoning: this is required for rapid response to intrusion detection. > Sounds good to me. However, I have a few questions on details: 1. Does "more restrictive" here refer to having a more specific (less wildcarded) classifier rule, or does it refer to the disposition rule being less likely to allow the packet through? Can we clarify the wording? 2. Does the above R86 imply that the agent must be able to tell the middlebox that this "new" rule should be matched to packets with a higher precedence then the "older", more highly wildcarded rule? Or do you believe a ridgidly defined canonical ordering system can cover that need? - Thanks, Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 15:56:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14486 for ; Thu, 13 Sep 2001 15:56: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 PAA24094; Thu, 13 Sep 2001 15:51: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 PAA24059 for ; Thu, 13 Sep 2001 15:51:11 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14330 for ; Thu, 13 Sep 2001 15:51:00 -0400 (EDT) Received: from asimu-u5.cisco.com (asimu-u5.cisco.com [128.107.162.97]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f8DJo7P21338; Thu, 13 Sep 2001 12:50:07 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by asimu-u5.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA28591; Thu, 13 Sep 2001 12:50:06 -0700 (PDT) Message-ID: <3BA10DEE.C5344953@cisco.com> Date: Thu, 13 Sep 2001 12:50:06 -0700 From: Adina Simu Organization: Cisco Systems X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema CC: Scott Brim , midcom@ietf.org Subject: Re: [midcom] Topology considerations documents 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 Christian Huitema wrote: > > > Except you assume that the agent knows a particular address [range] is > > inside or outside. How can it know that? It looks like you're > > assuming this "realm" infrastructure and administration is in place. > > In practical deployment, this is not a real problem. The requests will > be issued either by the first party, which definitely knows that it is > "inside" the firewalled area, or by a third party such as a SIP proxy, > which also must have a reasonable knowledge of the topology -- otherwise > it would not know which firewall to contact in the first place. This is a problem for NATs. Plus, with NATs the notions of Inside and Outside don't have the same significance as with FWs. There are a lot of examples where people are using NATs to solve other problems than connecting a 192.x.x.x network to the Internet. In those scenarios, I don't see any agent being able to make assumptions on where he sits and where the other endpoints sit. > > > In the case of wildcards an agent does need to let the middlebox know > > if it's talking about a rule for inside or outside addresses, but it > > can't know if a specific address is inside or outside. > > I would assume that the firewall definitely must know whether a specific > address is inside or outside. AFAIK, the firewall must have a rule for > resolving addresses to interfaces; you went on to assume rules that are > strictly based on addresses, which implicitly make the assumption that > addresses can be related to sides. Note that we could conceive a double > NAT scenario in which a rule strictly based on addresses would be > ambiguous. Could you please give an example for this NAT scenario? Thanks -Adina > > -- Christian Huitema > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom -- Adina Simu Software Engineer Core IP Eng - Services & Security IOS Technologies Division Phone: 408-525-1383 _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 17:01:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15855 for ; Thu, 13 Sep 2001 17:01: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 QAA26000; Thu, 13 Sep 2001 16:46: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 QAA25968 for ; Thu, 13 Sep 2001 16:46: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 ESMTP id QAA15498 for ; Thu, 13 Sep 2001 16:46:36 -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 f8DKjhx05736 for ; Thu, 13 Sep 2001 13:45:43 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-351.cisco.com [10.21.97.95]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ19034; Thu, 13 Sep 2001 13:45:42 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 13 Sep 2001 16:45:41 -0400 Date: Thu, 13 Sep 2001 16:45:41 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Re: Need to close too (was: Topology considerations documents) Message-ID: <20010913164541.Y1636@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 huitema@windows.microsoft.com on Thu, Sep 13, 2001 at 12:15:29PM -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, Sep 13, 2001 12:15:29PM -0700, Christian Huitema allegedly wrote: > Proposed requirement R86 (or whatever is the number): > > R86: It should possible to define specific filters that are more > restrictive than an overlapping generic filter, including filters that > would prevent traffic for a specific set of IP addresses and transport > parameters even if that traffic was authorized by an overlapping > "wildcard" filter. > > Reasoning: this is required for rapid response to intrusion detection. In the bullets, under "not yet discussed", for a 09/17 release. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 17:36: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 ESMTP id RAA16723 for ; Thu, 13 Sep 2001 17:36: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 RAA27740; Thu, 13 Sep 2001 17:30:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27649 for ; Thu, 13 Sep 2001 17:30:39 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16530 for ; Thu, 13 Sep 2001 17:30:32 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SXH3LN32; Thu, 13 Sep 2001 17:29:39 -0400 Message-Id: <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 13 Sep 2001 17:28:47 -0400 To: Scott Brim , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt In-Reply-To: <20010909163142.D1680@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, thanks. I'm still working on digesting this document but I do have a few comments. . Having the middlebox determine whether the addresses are inside or outside seems like an elegant solution. (At least, if it is a solution :-) I'm not yet convinced of that.) . I believe this proposal assumes that the middlebox understands the topology at least well enough to determine inside/outside as f(IP address). It seems to me that might not be true of all middleboxes. For example consider a simple 2-port middlebox that makes its forwarding decision based on 'forward the packet out whichever interface it did not arrive on'. . This proposal does not directly address middleboxes with multiple "inside" realms (such as network-based middleboxes). I suppose that could be addressed by modeling such a middlebox as multiple virtual middleboxes, each with a simple inside/outside as we have discussed in earlier emails. Of course, that really just pushes more of the problem onto a middlebox discovery mechanism. --Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 17:46:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16947 for ; Thu, 13 Sep 2001 17:46: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 RAA28063; Thu, 13 Sep 2001 17:36: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 RAA28027 for ; Thu, 13 Sep 2001 17:36:40 -0400 (EDT) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16733 for ; Thu, 13 Sep 2001 17:36:31 -0400 (EDT) Received: from 157.54.1.52 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Sep 2001 14:35:37 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Sep 2001 14:35:37 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Sep 2001 14:35:36 -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); Thu, 13 Sep 2001 14:34:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Re: Need to close too (was: Topology considerations documents) Date: Thu, 13 Sep 2001 14:34:58 -0700 Message-ID: Thread-Topic: [midcom] Re: Need to close too (was: Topology considerations documents) Thread-Index: AcE8l1KA815pFdDqS9u5KlLV4mku0QAA8fdQ From: "Christian Huitema" To: "Mark Duffy" , "Scott Brim" , X-OriginalArrivalTime: 13 Sep 2001 21:34:58.0267 (UTC) FILETIME=[EFBAAAB0:01C13C9B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA28028 Sender: 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 OK, there is a confusion in my initial phrasing. Try this: R86: It should possible to define rulesets that contain a more specific filter than an overlapping ruleset, and a different set of attributes. This should allow Midcom agent to request that a subset of the traffic that would be allowed by the overlapping ruleset be specifically disallowed. Reasoning: this is required for rapid response to intrusion detection. To answer Mark question, yes I expect that "when the filters of two rulesets overlap, the middlebox only executes the actions specified by the most specific ruleset." -- Christian Huitema > -----Original Message----- > From: Mark Duffy [mailto:mduffy@quarrytech.com] > Sent: Thursday, September 13, 2001 12:42 PM > To: Christian Huitema; Scott Brim; midcom@ietf.org > Subject: RE: [midcom] Re: Need to close too (was: Topology > considerations documents) > > At 12:15 PM 9/13/01 -0700, Christian Huitema wrote: > >Proposed requirement R86 (or whatever is the number): > > > >R86: It should possible to define specific filters that are more > >restrictive than an overlapping generic filter, including filters > that > >would prevent traffic for a specific set of IP addresses and > transport > >parameters even if that traffic was authorized by an overlapping > >"wildcard" filter. > > > >Reasoning: this is required for rapid response to intrusion > detection. > > > > Sounds good to me. However, I have a few questions on details: > > 1. Does "more restrictive" here refer to having a more specific (less > wildcarded) classifier rule, or does it refer to the disposition rule > being > less likely to allow the packet through? Can we clarify the wording? > > 2. Does the above R86 imply that the agent must be able to tell the > middlebox that this "new" rule should be matched to packets with a > higher > precedence then the "older", more highly wildcarded rule? Or do you > believe a ridgidly defined canonical ordering system can cover that > need? > > - Thanks, Mark > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 18:10:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17475 for ; Thu, 13 Sep 2001 18:10: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 SAA29025; Thu, 13 Sep 2001 18:02: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 SAA28994 for ; Thu, 13 Sep 2001 18:02: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 ESMTP id SAA17289 for ; Thu, 13 Sep 2001 18:01:54 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f8DM1EO17418 for ; Thu, 13 Sep 2001 15:01:14 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-351.cisco.com [10.21.97.95]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ20736; Thu, 13 Sep 2001 15:01:00 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 13 Sep 2001 18:00:59 -0400 Date: Thu, 13 Sep 2001 18:00:58 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Re: Need to close too (was: Topology considerations documents) Message-ID: <20010913180058.Z1636@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 huitema@windows.microsoft.com on Thu, Sep 13, 2001 at 02:34:58PM -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, Sep 13, 2001 02:34:58PM -0700, Christian Huitema allegedly wrote: > OK, there is a confusion in my initial phrasing. Try this: > > R86: It should possible to define rulesets that contain a more specific > filter than an overlapping ruleset, and a different set of attributes. > This should allow Midcom agent to request that a subset of the traffic > that would be allowed by the overlapping ruleset be specifically > disallowed. > > Reasoning: this is required for rapid response to intrusion detection. Amended. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 18:20:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17666 for ; Thu, 13 Sep 2001 18:20: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 SAA29523; Thu, 13 Sep 2001 18:15: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 SAA29494 for ; Thu, 13 Sep 2001 18:15:43 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17535 for ; Thu, 13 Sep 2001 18:15:35 -0400 (EDT) Received: from asimu-u5.cisco.com (asimu-u5.cisco.com [128.107.162.97]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8DMEgD23363; Thu, 13 Sep 2001 15:14:42 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by asimu-u5.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA28730; Thu, 13 Sep 2001 15:14:42 -0700 (PDT) Message-ID: <3BA12FD2.133E1C6@cisco.com> Date: Thu, 13 Sep 2001 15:14:42 -0700 From: Adina Simu Organization: Cisco Systems X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mark Duffy CC: Scott Brim , midcom@ietf.org Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt References: <3.0.5.32.20010913172847.0095c650@email.quarrytech.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 Mark, please see inline Mark Duffy wrote: > . I believe this proposal assumes that the middlebox understands the > topology at least well enough to determine inside/outside as f(IP address). > It seems to me that might not be true of all middleboxes. For example > consider a simple 2-port middlebox that makes its forwarding decision based > on 'forward the packet out whichever interface it did not arrive on'. I think I'm missing something in your example. What do you mean by "forward the packet out"? What if the packet is coming from "out"? Please be more specific. > . This proposal does not directly address middleboxes with multiple > "inside" realms (such as network-based middleboxes). I suppose that could Limiting for a minute the discussion to NAT middleboxes, the proposal works fine no matter how many "Inside" and "Outside" realms are. On this subject, there's something to be noted on the topology from Bob Penfield's draft: +-------------+ | | +------+ | Customer A | | | +---------------+ | +-----------+ | | | | 10.0.0.x | | | | | | | | | | Service | +-------------+ |Middle| | Provider | | Box +------+ | +-------------+ | | | | | | | | | 192.168.20.x | | Customer B | | | | | | +-----------+ | +---------------+ | 10.0.0.x | | | | | +------+ +-------------+ If you want connectivity in all possible combinations (Cust A - Cust B, Cust A - Serv Prov, Cust B - Serv Prov), this cannot be achieved with today's NATs (by this I mean NAT as described in NAT RFCs) - for routing reasons. I can provide more details if needed... Thanks -Adina > be addressed by modeling such a middlebox as multiple virtual middleboxes, > each with a simple inside/outside as we have discussed in earlier emails. > Of course, that really just pushes more of the problem onto a middlebox > discovery mechanism. > > --Mark > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom -- Adina Simu Software Engineer Core IP Eng - Services & Security IOS Technologies Division Phone: 408-525-1383 _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 18:25: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 ESMTP id SAA17729 for ; Thu, 13 Sep 2001 18: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 SAA29647; Thu, 13 Sep 2001 18:18: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 SAA29618 for ; Thu, 13 Sep 2001 18:18: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 ESMTP id SAA17575 for ; Thu, 13 Sep 2001 18:18:22 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SXH3LNRT; Thu, 13 Sep 2001 18:17:29 -0400 Message-Id: <3.0.5.32.20010913181640.0094d1f0@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 13 Sep 2001 18:16:40 -0400 To: "Christian Huitema" , From: Mark Duffy In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Precedence of wildcards Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org (subject line changed -- this is really a resumption of a thread from last week) At 02:34 PM 9/13/01 -0700, Christian Huitema wrote: >OK, there is a confusion in my initial phrasing. Try this: > >R86: It should possible to define rulesets that contain a more specific >filter than an overlapping ruleset, and a different set of attributes. >This should allow Midcom agent to request that a subset of the traffic >that would be allowed by the overlapping ruleset be specifically >disallowed. > >Reasoning: this is required for rapid response to intrusion detection. Christian, thanks. That sounds better. I agree with the requirement. >To answer Mark question, yes I expect that "when the filters of two >rulesets overlap, the middlebox only executes the actions specified by >the most specific ruleset." This is where we get back to the earlier thread about precedence of wildcards and a fixed canonical ordering scheme as you have proposed. Consider a firewall which usually has the following rule to permit access from the Internet to a web server: Rule1: SA=*, DA=1.2.3.4, prot=tcp, SP=*, DP=80: permit all incoming Now there is some kind of attack from 5.6.7.8. If I understand the motivation here, one might want to add a "rapid response" rule to block any acces from that host, i.e.: Rule2: SA=5.6.7.8, DA=*, prot=*, SP=*, DP=*: deny all Clearly we want Rule2 to be applied in preference to Rule1 when both may match. Now if I understand the canonical ordering idea, we pick some fixed significance order for the 5-tuple fields, such as MSB--> SA|DA|prot|SP|DP <--LSB so we have: SA DA prot SP DP Rule1: *.*.*.*.1.2.3.4.6.*.*.0.80 Rule2: 5.6.7.8.*.*.*.*.*.*.*.*.* Now I gather we order the rules according to: '1' bit > '0' bit > 'dont care' bit which means Rule2 > Rule1 and any traffic from 5.6.7.8 is therefore denied. In this case that is exactly what we want. But how can we be confident that this algorithm will give the desired result in all cases? Suppose the "usual" rule only allowed server access from subnet 8.9.10/24. Now we have Rule1a: SA=8.9.10.*, DA=1.2.3.4, prot=tcp, SP=*, DP=80: permit all incoming Now Rule1a > Rule2 and the rapid response ruledoesn't get the desired preference! Perhaps I am misunderstanding how the canonical ordering would be imposed? I know you advocate Interior/Exterior address and port view rather than Source/Dest but I do not believe that alters the basic question in this case. --Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 19:10:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18605 for ; Thu, 13 Sep 2001 19:10: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 TAA01048; Thu, 13 Sep 2001 19:03: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 TAA01021 for ; Thu, 13 Sep 2001 19:03:50 -0400 (EDT) Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18443 for ; Thu, 13 Sep 2001 19:03:44 -0400 (EDT) Received: from ns-ca.netscreen.com (ns-ca.netscreen.com [10.100.10.21]) by mail.netscreen.com (8.10.0/8.10.0) with ESMTP id f8DMGCW32707; Thu, 13 Sep 2001 15:16:12 -0700 Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Sep 2001 16:01:49 -0700 Message-ID: From: John LaCour To: "'Mark Duffy'" , Christian Huitema , midcom@ietf.org Subject: RE: [midcom] Precedence of wildcards Date: Thu, 13 Sep 2001 16:04:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I'd like to ask the group if the requirement to ensure that the precedence of rulesets is determinate can be defined as it must be possible to determine if a MIDCOM ruleset takes precedence over existing rulesets or is evaluated after other rules? I'd like to reduce the complexity of this requirement if at all possible. In many middleboxes today, there are a variety of 'things' which define policies. These include, administratively defined policies, ALGs, interaction with IDS (external or internal to the midbox), and others. I'm concerned about going down the path where MIDCOM has to learn about all of these things, when their rulesets change, etc. in order to specify an explicit precedence of its rules relative to everything else. If we limit precedence to "before everythings else" or "after everythings else" I think we're ok. I personally don't even think this is a real requirement. In all cases a MIDCOM rule's precedence should be before all currently existing rules, but after future rules. -John > -----Original Message----- > From: Mark Duffy [mailto:mduffy@quarrytech.com] > Sent: Thursday, September 13, 2001 3:17 PM > To: Christian Huitema; midcom@ietf.org > Subject: [midcom] Precedence of wildcards > > > (subject line changed -- this is really a resumption of a > thread from last > week) > > At 02:34 PM 9/13/01 -0700, Christian Huitema wrote: > >OK, there is a confusion in my initial phrasing. Try this: > > > >R86: It should possible to define rulesets that contain a > more specific > >filter than an overlapping ruleset, and a different set of > attributes. > >This should allow Midcom agent to request that a subset of > the traffic > >that would be allowed by the overlapping ruleset be specifically > >disallowed. > > > >Reasoning: this is required for rapid response to intrusion > detection. > > Christian, thanks. That sounds better. I agree with the requirement. > > > >To answer Mark question, yes I expect that "when the filters of two > >rulesets overlap, the middlebox only executes the actions > specified by > >the most specific ruleset." > > This is where we get back to the earlier thread about precedence of > wildcards and a fixed canonical ordering scheme as you have proposed. > > Consider a firewall which usually has the following rule to > permit access > from the Internet to a web server: > Rule1: SA=*, DA=1.2.3.4, prot=tcp, SP=*, DP=80: permit all incoming > > Now there is some kind of attack from 5.6.7.8. If I understand the > motivation here, one might want to add a "rapid response" > rule to block any > acces from that host, i.e.: > Rule2: SA=5.6.7.8, DA=*, prot=*, SP=*, DP=*: deny all > > Clearly we want Rule2 to be applied in preference to Rule1 > when both may > match. Now if I understand the canonical ordering idea, we > pick some fixed > significance order for the 5-tuple fields, such as > MSB--> SA|DA|prot|SP|DP <--LSB > so we have: > SA DA prot SP DP > Rule1: *.*.*.*.1.2.3.4.6.*.*.0.80 > Rule2: 5.6.7.8.*.*.*.*.*.*.*.*.* > > Now I gather we order the rules according to: > '1' bit > '0' bit > 'dont care' bit > which means Rule2 > Rule1 and any traffic from 5.6.7.8 is > therefore denied. > In this case that is exactly what we want. But how can we > be confident > that this algorithm will give the desired result in all > cases? Suppose the > "usual" rule only allowed server access from subnet > 8.9.10/24. Now we have > Rule1a: SA=8.9.10.*, DA=1.2.3.4, prot=tcp, SP=*, DP=80: > permit all incoming > Now Rule1a > Rule2 and the rapid response ruledoesn't get the desired > preference! > > Perhaps I am misunderstanding how the canonical ordering > would be imposed? > > I know you advocate Interior/Exterior address and port view > rather than > Source/Dest but I do not believe that alters the basic > question in this case. > > --Mark > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 19:18: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 ESMTP id TAA18701 for ; Thu, 13 Sep 2001 19:18: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 TAA01233; Thu, 13 Sep 2001 19:12: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 TAA01201 for ; Thu, 13 Sep 2001 19:12:47 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18652 for ; Thu, 13 Sep 2001 19:12:41 -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 f8DNBkD29460 for ; Thu, 13 Sep 2001 16:11:46 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-341.cisco.com [10.21.113.85]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ22274; Thu, 13 Sep 2001 16:11:44 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 13 Sep 2001 19:11:43 -0400 Date: Thu, 13 Sep 2001 19:11:42 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt Message-ID: <20010913191142.A1636@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <20010909163142.D1680@SBRIM-W2K> <3.0.5.32.20010913172847.0095c650@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.20010913172847.0095c650@email.quarrytech.com>; from mduffy@quarrytech.com on Thu, Sep 13, 2001 at 05:28:47PM -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Thu, Sep 13, 2001 05:28:47PM -0400, Mark Duffy allegedly wrote: > Scott, thanks. I'm still working on digesting this document but I do > have a few comments. > > . Having the middlebox determine whether the addresses are inside or > outside seems like an elegant solution. (At least, if it is a > solution :-) I'm not yet convinced of that.) I'm pleased at your first impression :-). We're just trying to keep things simple. > . I believe this proposal assumes that the middlebox understands the > topology at least well enough to determine inside/outside as f(IP > address). It seems to me that might not be true of all middleboxes. > For example consider a simple 2-port middlebox that makes its > forwarding decision based on 'forward the packet out whichever > interface it did not arrive on'. In this draft, inside and outside are not absolute, but are from the point of view of who is speaking, in particular an agent. When an agent says "outside okay" for an address, it means that address can refer to something in a different trust or addressing realm (across the middlebox). If a middlebox has multiple interfaces into the same addressling realm, it had better be configured to know that. That's a different case from the simple bump-in-the-wire, and inside/outside still work as above. > . This proposal does not directly address middleboxes with multiple > "inside" realms (such as network-based middleboxes). I suppose that > could be addressed by modeling such a middlebox as multiple virtual > middleboxes, each with a simple inside/outside as we have discussed in > earlier emails. Of course, that really just pushes more of the > problem onto a middlebox discovery mechanism. First, let me be sure out what you mean. Do you mean an agent in a service provider network which has two or more client networks, where the client networks have overlapping private address spaces? In that case what you call those multiple "inside" realms would be "outside" to the agent. Right? The inside/outside designation doesn't have to do with the clients, it's in the midcom protocol, and about the relationship between the agent and the middlebox. Or, do you mean networks which share a single address space but are only connected through the middlebox functioning as a router, and are thus all "inside" from the point of view of each other? I think I'll dismiss that one, since it doesn't involve the middlebox NAT function. Assuming you mean the former ... There was a little section that mentioned this (rummage rummage ...) Section 9. We didn't put any detail in there -- I thought it would be a distraction. Yes, you could make multiple virtual middleboxes out of them, but you can theoretically also use the informant address technique, as follows. It doesn't matter which of the networks the agent and clients are in, the agent and NAT behavior are the same. In fact let's even assume the worst case, that there are (at least) three overlapping address spaces, all connected by one NAT, for symmetry. From the point of view of the agent, all addressing realms except its own are "outside". If you're just setting up open admission, for example to receive calls, and you're accepting connections from outside of your addressing realm, then you don't care where from -- so you just say "outside okay", and the NAT does not need to distinguish between those outside realms -- when packets come in on any interface it will create a locally unique address for whoever sent them, and know the reverse transform. If you're setting up a specific rule, either for an address or an address range in a particular foreign addressing realm, then you must have acquired a target address (or address range) for that specific rule somewhere -- say from a SIP invitation or DNS -- and so you must already have a unique address for an informant, already allocated by the NAT. Given your informant address the NAT will know what to do, just as it knows what to do for incoming packets in the previous paragraph. Did I miss anything? If your mapping for the informant was provided by one middlebox and your data is going to go through a different one, you run into discovery problems. I think this issue is common to both proposed solutions, although it manifests itself differently in each. I suppose we need to make sure we're not requiring too much of discovery. Let's do that in another thread. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 19:19:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18723 for ; Thu, 13 Sep 2001 19:19:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01283; Thu, 13 Sep 2001 19:13: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 TAA01250 for ; Thu, 13 Sep 2001 19:13:34 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18661 for ; Thu, 13 Sep 2001 19:13:28 -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 f8DNCXD29903 for ; Thu, 13 Sep 2001 16:12:33 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-341.cisco.com [10.21.113.85]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ22300; Thu, 13 Sep 2001 16:12:31 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 13 Sep 2001 19:12:30 -0400 Date: Thu, 13 Sep 2001 19:12:30 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt Message-ID: <20010913191230.B1636@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <3BA12FD2.133E1C6@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BA12FD2.133E1C6@cisco.com>; from asimu@cisco.com on Thu, Sep 13, 2001 at 03:14:42PM -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, Sep 13, 2001 03:14:42PM -0700, Adina Simu allegedly wrote: > If you want connectivity in all possible combinations (Cust A - Cust B, > Cust A - Serv Prov, Cust B - Serv Prov), this cannot be achieved with > today's NATs (by this I mean NAT as described in NAT RFCs) - for routing > reasons. I can provide more details if needed... I should mention that my previous mail was based on theory :) _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 21:42:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21590 for ; Thu, 13 Sep 2001 21:42: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 VAA05499; Thu, 13 Sep 2001 21: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 VAA05466 for ; Thu, 13 Sep 2001 21:36:48 -0400 (EDT) Received: from web13804.mail.yahoo.com (web13804.mail.yahoo.com [216.136.175.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21524 for ; Thu, 13 Sep 2001 21:36:41 -0400 (EDT) Message-ID: <20010914013617.87541.qmail@web13804.mail.yahoo.com> Received: from [66.89.112.150] by web13804.mail.yahoo.com via HTTP; Thu, 13 Sep 2001 18:36:17 PDT Date: Thu, 13 Sep 2001 18:36:17 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [midcom] Precedence of wildcards To: John LaCour , 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 I agree with John. I like the simple requirement, as stated below. Let us not make the requirements so hard that it becomes impossible to design a MIDCOM protocol/language that can meets the requirements. The requirements at some point of time should be categorized as MUST/SHOULD/MAY. cheers, suresh --- John LaCour wrote: > I'd like to ask the group if the requirement to ensure > that the precedence of rulesets is determinate can be > defined as it must be possible to determine if a MIDCOM > ruleset takes precedence over existing rulesets or > is evaluated after other rules? > > I'd like to reduce the complexity of this requirement > if at all possible. > > In many middleboxes today, there are a variety of > 'things' which define policies. These include, > administratively defined policies, ALGs, interaction with > IDS (external or internal to the midbox), and others. > I'm concerned about going down the path where MIDCOM > has to learn about all of these things, when their > rulesets change, etc. in order to specify an > explicit precedence of its rules relative to everything > else. > > If we limit precedence to "before everythings else" or > "after everythings else" I think we're ok. > > I personally don't even think this is a real requirement. > In all cases a MIDCOM rule's precedence should be > before all currently existing rules, but after future > rules. > > -John > > > > -----Original Message----- > > From: Mark Duffy [mailto:mduffy@quarrytech.com] > > Sent: Thursday, September 13, 2001 3:17 PM > > To: Christian Huitema; midcom@ietf.org > > Subject: [midcom] Precedence of wildcards > > > > > > (subject line changed -- this is really a resumption of a > > thread from last > > week) > > > > At 02:34 PM 9/13/01 -0700, Christian Huitema wrote: > > >OK, there is a confusion in my initial phrasing. Try this: > > > > > >R86: It should possible to define rulesets that contain a > > more specific > > >filter than an overlapping ruleset, and a different set of > > attributes. > > >This should allow Midcom agent to request that a subset of > > the traffic > > >that would be allowed by the overlapping ruleset be specifically > > >disallowed. > > > > > >Reasoning: this is required for rapid response to intrusion > > detection. > > > > Christian, thanks. That sounds better. I agree with the requirement. > > > > > > >To answer Mark question, yes I expect that "when the filters of two > > >rulesets overlap, the middlebox only executes the actions > > specified by > > >the most specific ruleset." > > > > This is where we get back to the earlier thread about precedence of > > wildcards and a fixed canonical ordering scheme as you have proposed. > > > > Consider a firewall which usually has the following rule to > > permit access > > from the Internet to a web server: > > Rule1: SA=*, DA=1.2.3.4, prot=tcp, SP=*, DP=80: permit all incoming > > > > Now there is some kind of attack from 5.6.7.8. If I understand the > > motivation here, one might want to add a "rapid response" > > rule to block any > > acces from that host, i.e.: > > Rule2: SA=5.6.7.8, DA=*, prot=*, SP=*, DP=*: deny all > > > > Clearly we want Rule2 to be applied in preference to Rule1 > > when both may > > match. Now if I understand the canonical ordering idea, we > > pick some fixed > > significance order for the 5-tuple fields, such as > > MSB--> SA|DA|prot|SP|DP <--LSB > > so we have: > > SA DA prot SP DP > > Rule1: *.*.*.*.1.2.3.4.6.*.*.0.80 > > Rule2: 5.6.7.8.*.*.*.*.*.*.*.*.* > > > > Now I gather we order the rules according to: > > '1' bit > '0' bit > 'dont care' bit > > which means Rule2 > Rule1 and any traffic from 5.6.7.8 is > > therefore denied. > > In this case that is exactly what we want. But how can we > > be confident > > that this algorithm will give the desired result in all > > cases? Suppose the > > "usual" rule only allowed server access from subnet > > 8.9.10/24. Now we have > > Rule1a: SA=8.9.10.*, DA=1.2.3.4, prot=tcp, SP=*, DP=80: > > permit all incoming > > Now Rule1a > Rule2 and the rapid response ruledoesn't get the desired > > preference! > > > > Perhaps I am misunderstanding how the canonical ordering > > would be imposed? > > > > I know you advocate Interior/Exterior address and port view > > rather than > > Source/Dest but I do not believe that alters the basic > > question in this case. > > > > --Mark > > > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www1.ietf.org/mailman/listinfo/midcom > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 13 23:57: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 ESMTP id XAA26607 for ; Thu, 13 Sep 2001 23:57:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09019; Thu, 13 Sep 2001 23:55: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 XAA08988 for ; Thu, 13 Sep 2001 23:55:37 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26589 for ; Thu, 13 Sep 2001 23:55:30 -0400 (EDT) Received: from MDUFFY ([10.1.1.17]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SXH3LN6R; Thu, 13 Sep 2001 23:54:36 -0400 Message-Id: <3.0.5.32.20010913235342.00835b00@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 13 Sep 2001 23:53:42 -0400 To: Adina Simu From: Mark Duffy Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt Cc: Scott Brim , midcom@ietf.org In-Reply-To: <3BA12FD2.133E1C6@cisco.com> References: <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi Adina, see below... -Mark At 03:14 PM 9/13/01 -0700, Adina Simu wrote: >Mark, > >please see inline > >Mark Duffy wrote: >> . I believe this proposal assumes that the middlebox understands the >> topology at least well enough to determine inside/outside as f(IP address). >> It seems to me that might not be true of all middleboxes. For example >> consider a simple 2-port middlebox that makes its forwarding decision based >> on 'forward the packet out whichever interface it did not arrive on'. > >I think I'm missing something in your example. What do you mean by >"forward the packet out"? What if the packet is coming from "out"? >Please be more specific. I meant "forward the packet". I am talking about a middlebox with exactly 2 interfaces that has no idea what IP addresses are "inside" or what addresses are "outside". It has no knowledge of topology or routing information except that one of the interfaces connects to "inside" and the other to "outside". Packets received by it are processed for middlebox services then (assuming not dropped by the middlebox) transmitted on whichever of its 2 interfaces the packet was not received on. I believe there are middleboxes of this sort. I believe such a middlebox would be incapable of implementing your draft since it could not determine by examining target or informant addresses whether they resided inside or outside. >> . This proposal does not directly address middleboxes with multiple >> "inside" realms (such as network-based middleboxes). I suppose that could > >Limiting for a minute the discussion to NAT middleboxes, the proposal >works fine no matter how many "Inside" and "Outside" realms are. In the diagram below, suppose Customer A and B each have a host 10.0.0.1 and the middle box is doing NAT (not NAPT). Suppose Customer A 10.0.0.1 is bound to 192.168.20.1. Suppose Customer B 10.0.0.1 is bound to 192.168.20.2. Now, when a midcom agent asks "what is the NAT binding for 10.0.0.1", how does the middlebox respond? > >On this subject, there's something to be noted on the topology from Bob >Penfield's draft: > > +-------------+ > | | +------+ > | Customer A | | | +---------------+ > | +-----------+ | | | > | 10.0.0.x | | | | | > | | | | | Service | > +-------------+ |Middle| | Provider | > | Box +------+ | > +-------------+ | | | | > | | | | | 192.168.20.x | > | Customer B | | | | | > | +-----------+ | +---------------+ > | 10.0.0.x | | | > | | +------+ > +-------------+ [snip] _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 00:38: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 ESMTP id AAA27084 for ; Fri, 14 Sep 2001 00:38: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 AAA10221; Fri, 14 Sep 2001 00:32: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 AAA10147 for ; Fri, 14 Sep 2001 00:32:53 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27025 for ; Fri, 14 Sep 2001 00:32:52 -0400 (EDT) Received: from asimu-u5.cisco.com (asimu-u5.cisco.com [128.107.162.97]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8E4VqD18870; Thu, 13 Sep 2001 21:31:52 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by asimu-u5.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id VAA00305; Thu, 13 Sep 2001 21:31:52 -0700 (PDT) Message-ID: <3BA18838.BE176E4B@cisco.com> Date: Thu, 13 Sep 2001 21:31:52 -0700 From: Adina Simu Organization: Cisco Systems X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mark Duffy CC: Scott Brim , midcom@ietf.org Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt References: <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <3.0.5.32.20010913235342.00835b00@email.quarrytech.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 Mark, please see inline... Mark Duffy wrote: > I meant "forward the packet". I am talking about a middlebox with exactly > 2 interfaces that has no idea what IP addresses are "inside" or what > addresses are "outside". It has no knowledge of topology or routing > information except that one of the interfaces connects to "inside" and the > other to "outside". Packets received by it are processed for middlebox > services then (assuming not dropped by the middlebox) transmitted on > whichever of its 2 interfaces the packet was not received on. I believe > there are middleboxes of this sort. I believe such a middlebox would be I'm not familiar with such middleboxes... I don't see how NAT would run on such a box. Not sure about FW. > incapable of implementing your draft since it could not determine by > examining target or informant addresses whether they resided inside or > outside. > In the diagram below, suppose Customer A and B each have a host 10.0.0.1 > and the middle box is doing NAT (not NAPT). Suppose Customer A 10.0.0.1 is > bound to 192.168.20.1. Suppose Customer B 10.0.0.1 is bound to > 192.168.20.2. Now, when a midcom agent asks "what is the NAT binding for > 10.0.0.1", how does the middlebox respond? Where is the agent located? If it's in the SP realm, the only way for it to aquire the 10.x address would be through a packet coming from a 10.x net - which would have been translated, so the source IP in the packet header would be either 192.168.20.1 or .2 - based on that NAT will identify which 10.x ... The idea behind the informant address is very basic: suppose a pre-midcom network, where ALG reside on the NAT box. When NAT has to translate an embedded address, it figures out the topology information (the realm where the address was originated and where is it going) from the IP addresses in the header. An agent should provide the same info to a middlebox doing NAT. Thanks -Adina > > > > >On this subject, there's something to be noted on the topology from Bob > >Penfield's draft: > > > > +-------------+ > > | | +------+ > > | Customer A | | | +---------------+ > > | +-----------+ | | | > > | 10.0.0.x | | | | | > > | | | | | Service | > > +-------------+ |Middle| | Provider | > > | Box +------+ | > > +-------------+ | | | | > > | | | | | 192.168.20.x | > > | Customer B | | | | | > > | +-----------+ | +---------------+ > > | 10.0.0.x | | | > > | | +------+ > > +-------------+ > [snip] -- Adina Simu Software Engineer Core IP Eng - Services & Security IOS Technologies Division Phone: 408-525-1383 _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 08:32:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16413 for ; Fri, 14 Sep 2001 08:32: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 IAA26774; Fri, 14 Sep 2001 08:29: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 IAA26746 for ; Fri, 14 Sep 2001 08:29:24 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16292 for ; Fri, 14 Sep 2001 08:29:52 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A81AAA620130; Fri, 14 Sep 2001 08:29:14 -0400 Message-ID: <000d01c13d18$02b65de0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Adina Simu" , "Mark Duffy" Cc: "Scott Brim" , References: <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <3BA12FD2.133E1C6@cisco.com> Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt Date: Fri, 14 Sep 2001 08:23:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit > On this subject, there's something to be noted on the topology from Bob > Penfield's draft: > > +-------------+ > | | +------+ > | Customer A | | | +---------------+ > | +-----------+ | | | > | 10.0.0.x | | | | | > | | | | | Service | > +-------------+ |Middle| | Provider | > | Box +------+ | > +-------------+ | | | | > | | | | | 192.168.20.x | > | Customer B | | | | | > | +-----------+ | +---------------+ > | 10.0.0.x | | | > | | +------+ > +-------------+ > > If you want connectivity in all possible combinations (Cust A - Cust B, > Cust A - Serv Prov, Cust B - Serv Prov), this cannot be achieved with > today's NATs (by this I mean NAT as described in NAT RFCs) - for routing > reasons. I can provide more details if needed... > Existing NAT boxes may not do this today, but there are a number of VOIP service providers that want devices like this and there are people building them. MIDCOM needs to consider both existing middlebox and those that people are developing today. Currently, product developers must use a proprietary protocol to talk to these middleboxes. They (we) would like to be able to use a standardized protocol in the near future. The solution proposed in draft-brim-midcom-inandout-00.txt does not cover the case of CustomerA to Customer B traffic. If all you have two 10.0.0.x addresses (informat & target), there is no way for the middlebox to tell which private realm those addresses are in unless the agent in the service provider gives it a hint. cheers, (-:bob _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 08:58:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17138 for ; Fri, 14 Sep 2001 08:58:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27430; Fri, 14 Sep 2001 08:51: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 IAA27401 for ; Fri, 14 Sep 2001 08:51:26 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17056 for ; Fri, 14 Sep 2001 08:51:54 -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 f8ECotD03348; Fri, 14 Sep 2001 05:50:55 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-210.cisco.com [10.21.112.210]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ28460; Fri, 14 Sep 2001 05:50:54 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Fri, 14 Sep 2001 08:50:54 -0400 Date: Fri, 14 Sep 2001 08:50:54 -0400 From: Scott Brim To: Bob Penfield Cc: midcom@ietf.org Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt Message-ID: <20010914085054.D1556@SBRIM-W2K> Mail-Followup-To: Scott Brim , Bob Penfield , midcom@ietf.org References: <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <3BA12FD2.133E1C6@cisco.com> <000d01c13d18$02b65de0$2300000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000d01c13d18$02b65de0$2300000a@acmepacket.com>; from bpenfield@acmepacket.com on Fri, Sep 14, 2001 at 08:23:07AM -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 Fri, Sep 14, 2001 08:23:07AM -0400, Bob Penfield allegedly wrote: > > On this subject, there's something to be noted on the topology from Bob > > Penfield's draft: > > > > +-------------+ > > | | +------+ > > | Customer A | | | +---------------+ > > | +-----------+ | | | > > | 10.0.0.x | | | | | > > | | | | | Service | > > +-------------+ |Middle| | Provider | > > | Box +------+ | > > +-------------+ | | | | > > | | | | | 192.168.20.x | > > | Customer B | | | | | > > | +-----------+ | +---------------+ > > | 10.0.0.x | | | > > | | +------+ > > +-------------+ > > > > If you want connectivity in all possible combinations (Cust A - Cust B, > > Cust A - Serv Prov, Cust B - Serv Prov), this cannot be achieved with > > today's NATs (by this I mean NAT as described in NAT RFCs) - for routing > > reasons. I can provide more details if needed... > > > Existing NAT boxes may not do this today, but there are a number of VOIP > service providers that want devices like this and there are people building > them. MIDCOM needs to consider both existing middlebox and those that people > are developing today. Currently, product developers must use a proprietary > protocol to talk to these middleboxes. They (we) would like to be able to > use a standardized protocol in the near future. The solution proposed in > draft-brim-midcom-inandout-00.txt does not cover the case of CustomerA to > Customer B traffic. If all you have two 10.0.0.x addresses (informat & > target), there is no way for the middlebox to tell which private realm those > addresses are in unless the agent in the service provider gives it a hint. Please read the draft and/or the mail more carefully. The informant address will not be a 10.0.0.x address. The informant address will have already been mapped through the NAT, since the agent is already exchanging packets with it. It will be locally unique in the realm of the agent, e.g. 192.168.20.241. In the case of SIP, when you receive an invitation to 10.0.0.9, you will receive it in a packet with a source address of 192.168.20.241. That's your informant address. When you pass that back to the NAT as the informant address, since it already has a mapping for the informant address, the NAT will know how to resolve your request. You already have all the hint you need. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 09:11: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 ESMTP id JAA17370 for ; Fri, 14 Sep 2001 09:11: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 JAA27952; Fri, 14 Sep 2001 09:07: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 JAA27929 for ; Fri, 14 Sep 2001 09:07:25 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17298 for ; Fri, 14 Sep 2001 09:07:52 -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 f8ED4uO11183; Fri, 14 Sep 2001 06:04:56 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-210.cisco.com [10.21.112.210]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ28527; Fri, 14 Sep 2001 06:06:53 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Fri, 14 Sep 2001 09:06:53 -0400 Date: Fri, 14 Sep 2001 09:06:53 -0400 From: Scott Brim To: John LaCour Cc: "'Mark Duffy'" , Christian Huitema , midcom@ietf.org Subject: Re: [midcom] Precedence of wildcards Message-ID: <20010914090653.E1556@SBRIM-W2K> Mail-Followup-To: Scott Brim , John LaCour , 'Mark Duffy' , Christian Huitema , 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 jlacour@netscreen.com on Thu, Sep 13, 2001 at 04:04:00PM -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, Sep 13, 2001 04:04:00PM -0700, John LaCour allegedly wrote: > I'd like to ask the group if the requirement to ensure > that the precedence of rulesets is determinate can be > defined as it must be possible to determine if a MIDCOM > ruleset takes precedence over existing rulesets or > is evaluated after other rules? > > I'd like to reduce the complexity of this requirement > if at all possible. R85: It must be possible to deterministically predict the behavior of the middlebox in the presence of overlapping rules. I think that does what you want. Christian introduced that one, right? We're spending a lot of time on the next working group's business. I guess we're impatient to get on with it. So let's finish the requirements. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 09:29:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17602 for ; Fri, 14 Sep 2001 09:29: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 JAA28183; Fri, 14 Sep 2001 09:23: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 JAA28154 for ; Fri, 14 Sep 2001 09:22:59 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17563 for ; Fri, 14 Sep 2001 09:23:26 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A4AEF8130136; Fri, 14 Sep 2001 09:22:54 -0400 Message-ID: <005201c13d1f$7340ed80$2300000a@acmepacket.com> From: "Bob Penfield" To: "Adina Simu" , "Mark Duffy" Cc: "Scott Brim" , References: <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <3.0.5.32.20010913235342.00835b00@email.quarrytech.com> <3BA18838.BE176E4B@cisco.com> Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt Date: Fri, 14 Sep 2001 09:16:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.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: "Adina Simu" To: "Mark Duffy" Cc: "Scott Brim" ; Sent: Friday, September 14, 2001 12:31 AM Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt > Mark, > > please see inline... > > Mark Duffy wrote: > > I meant "forward the packet". I am talking about a middlebox with exactly > > 2 interfaces that has no idea what IP addresses are "inside" or what > > addresses are "outside". It has no knowledge of topology or routing > > information except that one of the interfaces connects to "inside" and the > > other to "outside". Packets received by it are processed for middlebox > > services then (assuming not dropped by the middlebox) transmitted on > > whichever of its 2 interfaces the packet was not received on. I believe > > there are middleboxes of this sort. I believe such a middlebox would be > > I'm not familiar with such middleboxes... I don't see how NAT would run > on such a box. Not sure about FW. > > > incapable of implementing your draft since it could not determine by > > examining target or informant addresses whether they resided inside or > > outside. > > > > > In the diagram below, suppose Customer A and B each have a host 10.0.0.1 > > and the middle box is doing NAT (not NAPT). Suppose Customer A 10.0.0.1 is > > bound to 192.168.20.1. Suppose Customer B 10.0.0.1 is bound to > > 192.168.20.2. Now, when a midcom agent asks "what is the NAT binding for > > 10.0.0.1", how does the middlebox respond? > > Where is the agent located? If it's in the SP realm, the only way for it > to aquire the 10.x address would be through a packet coming from a 10.x > net - which would have been translated, so the source IP in the packet > header would be either 192.168.20.1 or .2 - based on that NAT will > identify which 10.x ... > > The idea behind the informant address is very basic: suppose a > pre-midcom network, where ALG reside on the NAT box. When NAT has to > translate an embedded address, it figures out the topology information > (the realm where the address was originated and where is it going) from > the IP addresses in the header. An agent should provide the same info to > a middlebox doing NAT. > When you say "the same info", I believe that part of that info is the interface that the packets arrive on. The question is, how does a midcom agent provide that piece of information. Supplying 2 addresses from a private address space is no more helpful that providing 1 if you have more than one overlapping private address spaces. Given that, how does a midcom agent provide "the realm where the address was originated and where is it going"? _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 10:31: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 ESMTP id KAA18748 for ; Fri, 14 Sep 2001 10:31: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 KAA29709; Fri, 14 Sep 2001 10:18: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 KAA29681 for ; Fri, 14 Sep 2001 10:18:14 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18447 for ; Fri, 14 Sep 2001 10:18:41 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8EEHgD13652; Fri, 14 Sep 2001 07:17:42 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-30.cisco.com [10.82.192.30]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAD06276; Fri, 14 Sep 2001 07:17:41 -0700 (PDT) Message-Id: <5.1.0.14.0.20010914101854.00a68bf0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 14 Sep 2001 10:19:29 -0400 To: Mark Duffy , midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Terminology discussion - regroup In-Reply-To: <3.0.5.32.20010910182439.00a2fc50@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org It doesn't yet appear that we have agreement on the proposed terminology. Where do we stand with it? Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 10:52:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19163 for ; Fri, 14 Sep 2001 10:52: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 KAA00560; Fri, 14 Sep 2001 10:43: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 KAA00531 for ; Fri, 14 Sep 2001 10:43:33 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19056 for ; Fri, 14 Sep 2001 10:44:01 -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 f8EEh3x29642 for ; Fri, 14 Sep 2001 07:43:03 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-210.cisco.com [10.21.112.210]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ29204; Fri, 14 Sep 2001 07:43:02 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Fri, 14 Sep 2001 10:43:01 -0400 Date: Fri, 14 Sep 2001 10:43:01 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt Message-ID: <20010914104301.H1556@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <3.0.5.32.20010913235342.00835b00@email.quarrytech.com> <3BA18838.BE176E4B@cisco.com> <005201c13d1f$7340ed80$2300000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <005201c13d1f$7340ed80$2300000a@acmepacket.com>; from bpenfield@acmepacket.com on Fri, Sep 14, 2001 at 09:16:22AM -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 Fri, Sep 14, 2001 09:16:22AM -0400, Bob Penfield allegedly wrote: > > The idea behind the informant address is very basic: suppose a > > pre-midcom network, where ALG reside on the NAT box. When NAT has to > > translate an embedded address, it figures out the topology information > > (the realm where the address was originated and where is it going) from > > the IP addresses in the header. An agent should provide the same info to > > a middlebox doing NAT. > > > When you say "the same info", I believe that part of that info is the > interface that the packets arrive on. The question is, how does a midcom > agent provide that piece of information. Supplying 2 addresses from a > private address space is no more helpful that providing 1 if you have more > than one overlapping private address spaces. Given that, how does a midcom > agent provide "the realm where the address was originated and where is it > going"? I already answered this in my previous message. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 10:57:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19291 for ; Fri, 14 Sep 2001 10:57: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 KAA00739; Fri, 14 Sep 2001 10:52: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 KAA00706 for ; Fri, 14 Sep 2001 10:52:16 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19176 for ; Fri, 14 Sep 2001 10:52:44 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f8EEpkx04891 for ; Fri, 14 Sep 2001 07:51:46 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-210.cisco.com [10.21.112.210]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ29295; Fri, 14 Sep 2001 07:51:45 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Fri, 14 Sep 2001 10:51:44 -0400 Date: Fri, 14 Sep 2001 10:51:44 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Terminology discussion - regroup Message-ID: <20010914105144.J1556@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <3.0.5.32.20010910182439.00a2fc50@email.quarrytech.com> <5.1.0.14.0.20010914101854.00a68bf0@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20010914101854.00a68bf0@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Fri, Sep 14, 2001 at 10:19:29AM -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 Fri, Sep 14, 2001 10:19:29AM -0400, Melinda Shore allegedly wrote: > It doesn't yet appear that we have agreement on the proposed > terminology. Where do we stand with it? I have no objections to anything proposed. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 11:14:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19649 for ; Fri, 14 Sep 2001 11:14: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 LAA01223; Fri, 14 Sep 2001 11:02: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 LAA01194 for ; Fri, 14 Sep 2001 11:02:39 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19431 for ; Fri, 14 Sep 2001 11:03:07 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SXH3L3RV; Fri, 14 Sep 2001 11:02:08 -0400 Message-Id: <3.0.5.32.20010914110117.00950b00@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 14 Sep 2001 11:01:17 -0400 To: Melinda Shore , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Terminology discussion - regroup In-Reply-To: <5.1.0.14.0.20010914101854.00a68bf0@mira-sjc5-4.cisco.com> References: <3.0.5.32.20010910182439.00a2fc50@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 10:19 AM 9/14/01 -0400, Melinda Shore wrote: >It doesn't yet appear that we have agreement on the proposed >terminology. Where do we stand with it? > >Melinda After a great deal of discussion on the list I posted an updated proposal on Sep 10 which Melinda sent out again on Tue, 11 Sep 2001 09:16:46 -0400 with a call for comments. My personal assesment is that: -I myself agree with the proposal :-) but tire of the issue -Scott Brim is satisfied with it -I believe John LaCour and Bob Penfield are satisfied with it as they commented on certain aspects. -I suspect Christian is not entirely happy with it but I don't know of specific changes he would like made. -Suresh has some significant disagreements. He would like to see different terms used in several cases and I believe he disagrees somehat with what the concept of Ruleset encompasses (vs middlebox "configuration"). -I don't recall any other input. If I've misrepresented anyone, I'm sure they'll speak up and my most sincere apologies. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 11:25:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19936 for ; Fri, 14 Sep 2001 11:25: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 LAA01419; Fri, 14 Sep 2001 11:13: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 LAA01390 for ; Fri, 14 Sep 2001 11:13:15 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19643 for ; Fri, 14 Sep 2001 11:13: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 f8EFCjD15359 for ; Fri, 14 Sep 2001 08:12:45 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-210.cisco.com [10.21.112.210]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ29513; Fri, 14 Sep 2001 08:12:44 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Fri, 14 Sep 2001 11:12:44 -0400 Date: Fri, 14 Sep 2001 11:12:44 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Topology considerations documents Message-ID: <20010914111244.L1556@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 huitema@windows.microsoft.com on Thu, Sep 13, 2001 at 10:52:23AM -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, Sep 13, 2001 10:52:23AM -0700, Christian Huitema allegedly wrote: > > Except you assume that the agent knows a particular address [range] is > > inside or outside. How can it know that? It looks like you're > > assuming this "realm" infrastructure and administration is in place. > > In practical deployment, this is not a real problem. The requests will > be issued either by the first party, which definitely knows that it is > "inside" the firewalled area, or by a third party such as a SIP proxy, > which also must have a reasonable knowledge of the topology -- otherwise > it would not know which firewall to contact in the first place. There is no problem when you are creating a ruleset for yourself, so that others can reach you. However, suppose an invitation comes to you with some previously unseen address. How do you know if that address is inside or outside? When you send an invitation in return, do you use an inside address or an outside address for yourself? Either - the agent knows the network topology and whether any particular address prefix is inside or outside (don't do this!) - the agent receives a "realm ID" with the invitation and knows if that realm is inside or outside (you've seen my concerns with this) - the agent goes ahead and requests a ruleset to reach that address, and depends on the middlebox to know if one is really necessary. Let's assume the agent asks the middlebox. In that case, how can it phrase its ruleset query? It doesn't know if the target address is inside or outside. I suppose we could change your inside/outside syntax to be inside and "maybe in or out", but I don't know if that leads to deterministic behavior. Also, suppose an agent is in an ISP and is trying to arrange communication between two clients which are both "outside" from the point of view of the agent. You don't have inside and outside. I think you need syntax which doesn't make assumptions about topology. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 11:33: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 ESMTP id LAA20216 for ; Fri, 14 Sep 2001 11:33: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 LAA01770; Fri, 14 Sep 2001 11:27: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 LAA01739 for ; Fri, 14 Sep 2001 11:27: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 ESMTP id LAA20106 for ; Fri, 14 Sep 2001 11:27:33 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SXH3L3V8; Fri, 14 Sep 2001 11:26:34 -0400 Message-Id: <3.0.5.32.20010914112543.0094d510@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 14 Sep 2001 11:25:43 -0400 To: Scott Brim , midcom@ietf.org From: Mark Duffy In-Reply-To: <20010913191142.A1636@SBRIM-W2K> References: <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <20010909163142.D1680@SBRIM-W2K> <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] draft-brim-midcom-inandout vs mb with no topology knowledge Sender: 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, see comments below... At 07:11 PM 9/13/01 -0400, Scott Brim wrote: >On Thu, Sep 13, 2001 05:28:47PM -0400, Mark Duffy allegedly wrote: [snip] >> . I believe this proposal assumes that the middlebox understands the >> topology at least well enough to determine inside/outside as f(IP >> address). It seems to me that might not be true of all middleboxes. >> For example consider a simple 2-port middlebox that makes its >> forwarding decision based on 'forward the packet out whichever >> interface it did not arrive on'. > >In this draft, inside and outside are not absolute, but are from the >point of view of who is speaking, in particular an agent. When an agent >says "outside okay" for an address, it means that address can refer to >something in a different trust or addressing realm (across the >middlebox). Suppose the middlebox is a very simple one that only knows that interface A connects to one side (lets call it the inside") and interface B connects to the other side ("outside"). I.e. "inside" and "outside" are *defined by* interfaces A and B. The middlebox applies rules to the traffic based on packet n-tuple, interface the packet arrived on, and transport layer state accumulated in the middlebox. Now, if I understand your draft the agent in effect says: "Install this ruleset, unless it is not needed because both the source and destination addresses are on the same 'side'. Here is an informant address also, to help you decide." It seems to me, that this simple middlebox has no idea where any particular addresse lie, and so I am wondering how it could possibly deal with such a request from an agent. >If a middlebox has multiple interfaces into the same addressling realm, >it had better be configured to know that. That's a different case from >the simple bump-in-the-wire, and inside/outside still work as above. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 11:47: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 ESMTP id LAA20477 for ; Fri, 14 Sep 2001 11:47: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 LAA02344; Fri, 14 Sep 2001 11:42: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 LAA02317 for ; Fri, 14 Sep 2001 11:42:51 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20427 for ; Fri, 14 Sep 2001 11:43:19 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A57AE50000AA; Fri, 14 Sep 2001 11:42:50 -0400 Message-ID: <00a601c13d32$e0672600$2300000a@acmepacket.com> From: "Bob Penfield" To: "Scott Brim" Cc: References: <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <3BA12FD2.133E1C6@cisco.com> <000d01c13d18$02b65de0$2300000a@acmepacket.com> <20010914085054.D1556@SBRIM-W2K> Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt Date: Fri, 14 Sep 2001 11:35:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Scott Brim" > > > +-------------+ > > > | | +------+ > > > | Customer A | | | +---------------+ > > > | +-----------+ | | | > > > | 10.0.0.x | | | | | > > > | | | | | Service | > > > +-------------+ |Middle| | Provider | > > > | Box +------+ | > > > +-------------+ | | | | > > > | | | | | 192.168.20.x | > > > | Customer B | | | | | > > > | +-----------+ | +---------------+ > > > | 10.0.0.x | | | > > > | | +------+ > > > +-------------+ > > > > > Please read the draft and/or the mail more carefully. The informant > address will not be a 10.0.0.x address. The informant address will have > already been mapped through the NAT, since the agent is already > exchanging packets with it. It will be locally unique in the realm of > the agent, e.g. 192.168.20.241. In the case of SIP, when you receive an > invitation to 10.0.0.9, you will receive it in a packet with a source > address of 192.168.20.241. That's your informant address. When you > pass that back to the NAT as the informant address, since it already has > a mapping for the informant address, the NAT will know how to resolve > your request. You already have all the hint you need. I see. However, this assumes that signalling packets traverse the same middlebox that the application entities want to put the data packets through. But anyway, I think I see how this can be done, let me give an example. Using the picture above, and assuming the midcom agent is collocated with an application entity in SP. The NAT bindings between application entities in A, B, and SP would need to be established before any application signaling traffic. For example, the application entities in A and B could initiate TCP connections to the application entity (let's call them AEs) in SP. For an application session to be established between A and B, a signaling message would be sent from the AE in A to the AE in SP. The AE in SP determines that this signaling message should go to the AE in B. The signaling message contains the private IP address in A that must be NAT'd to a public address in SP in order to get through the middlebox. The AE in SP needs to request a NAT binding, but what it wants is "for all packets arriving on the interface from customer B with a destination address equal to a public address you (the middlebox) assign, forward them to the interface to customer A and change the destination address to this private address". Now, in order to communicate this, it needs to send both previously established public addresses associated with AE NAT bindings. Let me give some concrete values. - connection from AE-A to AE-SP gets 192.168.20.241 as a public address - connection from AE-B to AE-SP gets 192.168.20.242 as a public address - endpoint A is 10.0.0.9 in A - as the signaling traverses AE-SP, AE-SP determines that AE-B is the next hop, the midcom agent needs to get a public address for endpoint A as a target for the data packets that will be coming from the endpoint in B (AE-SP assumes the endpoint is in B, or beyond, because the next hop AE is in B). The request to the middlebox would look something like this: Ingress Informant = 192.168.20.242 (i.e. realm B) Incoming Source = any Incoming Destination = pick one Egress Informant = 192.168.20.241 (i.e. Realm A) Outgoing Source = pick one Outgoing Destination = 10.0.0.9 - The signaling going back from B to A would have a similar ruleset with the Ingress & Egress informants swapped, and the Outgoing Destination would be a private address in B. Does this seem correct? (-:bob _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 11: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 ESMTP id LAA20569 for ; Fri, 14 Sep 2001 11:52: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 LAA02420; Fri, 14 Sep 2001 11:43: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 LAA02388 for ; Fri, 14 Sep 2001 11:43:38 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20453 for ; Fri, 14 Sep 2001 11:44:05 -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 f8EFh7D04576 for ; Fri, 14 Sep 2001 08:43:07 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-210.cisco.com [10.21.112.210]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ29975; Fri, 14 Sep 2001 08:43:06 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Fri, 14 Sep 2001 11:43:05 -0400 Date: Fri, 14 Sep 2001 11:43:05 -0400 From: Scott Brim To: midcom@ietf.org Message-ID: <20010914114305.O1556@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <20010909163142.D1680@SBRIM-W2K> <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <20010913191142.A1636@SBRIM-W2K> <3.0.5.32.20010914112543.0094d510@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.20010914112543.0094d510@email.quarrytech.com>; from mduffy@quarrytech.com on Fri, Sep 14, 2001 at 11:25:43AM -0400 Subject: [midcom] Re: draft-brim-midcom-inandout vs mb with no topology knowledge Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Fri, Sep 14, 2001 11:25:43AM -0400, Mark Duffy allegedly wrote: > Scott, see comments below... > > At 07:11 PM 9/13/01 -0400, Scott Brim wrote: > >On Thu, Sep 13, 2001 05:28:47PM -0400, Mark Duffy allegedly wrote: > [snip] > >> . I believe this proposal assumes that the middlebox understands the > >> topology at least well enough to determine inside/outside as f(IP > >> address). It seems to me that might not be true of all middleboxes. > >> For example consider a simple 2-port middlebox that makes its > >> forwarding decision based on 'forward the packet out whichever > >> interface it did not arrive on'. > > > >In this draft, inside and outside are not absolute, but are from the > >point of view of who is speaking, in particular an agent. When an agent > >says "outside okay" for an address, it means that address can refer to > >something in a different trust or addressing realm (across the > >middlebox). > > Suppose the middlebox is a very simple one that only knows that interface A > connects to one side (lets call it the inside") and interface B connects to > the other side ("outside"). I.e. "inside" and "outside" are *defined by* > interfaces A and B. The middlebox applies rules to the traffic based on > packet n-tuple, interface the packet arrived on, and transport layer state > accumulated in the middlebox. Now, if I understand your draft the agent in > effect says: > > "Install this ruleset, unless it is not needed because both the > source and destination addresses are on the same 'side'. Here is > an informant address also, to help you decide." > > It seems to me, that this simple middlebox has no idea where any particular > addresse lie, and so I am wondering how it could possibly deal with such a > request from an agent. The worst case you're describing is a complex private network, with routers, on one side, and the public network on the other side, while the device in the middle has no knowledge whatsoever -- it's just a firewall with whatever holes are explicitly punched through. I think you're right. I think we don't handle that case (unless someone can tell me how). If the firewall had an address/mask pair configured on the "inside" interface, even if it had nothing more, then we could. I hope you won't say, "Aha, I found an unusual case you can't handle, therefore we have to use the alternative, even though it adds much more complexity for the much more common cases". ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 11: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 ESMTP id LAA20729 for ; Fri, 14 Sep 2001 11:58: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 LAA02728; Fri, 14 Sep 2001 11:52: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 LAA02645 for ; Fri, 14 Sep 2001 11:52:42 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20609 for ; Fri, 14 Sep 2001 11:53:10 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SXH3L3YH; Fri, 14 Sep 2001 11:52:08 -0400 Message-Id: <3.0.5.32.20010914115115.00950b30@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 14 Sep 2001 11:51:15 -0400 To: Scott Brim , midcom@ietf.org From: Mark Duffy In-Reply-To: <20010913191142.A1636@SBRIM-W2K> References: <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <20010909163142.D1680@SBRIM-W2K> <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] multicontext mb and draft-brim-midcom-inandout Sender: 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, comments on the 2nd part (I split the issues) --Thanks, Mark At 07:11 PM 9/13/01 -0400, Scott Brim wrote: [snip] >> . This proposal does not directly address middleboxes with multiple >> "inside" realms (such as network-based middleboxes). I suppose that >> could be addressed by modeling such a middlebox as multiple virtual >> middleboxes, each with a simple inside/outside as we have discussed in >> earlier emails. Of course, that really just pushes more of the >> problem onto a middlebox discovery mechanism. > >First, let me be sure out what you mean. Do you mean an agent in a >service provider network which has two or more client networks, where >the client networks have overlapping private address spaces? Yes. > In that >case what you call those multiple "inside" realms would be "outside" to >the agent. Right? The inside/outside designation doesn't have to do >with the clients, it's in the midcom protocol, and about the >relationship between the agent and the middlebox. I don't understand that, actually. I have always viewed the realms (which we are here reducing to "in" and "out") as being an administrative concept defined by the administrator of a realm. Since middleboxes cost money, they are installed only when a particular need exists such as to provide firewall to protect access to a domain, or to provide NAT so that a private-address domain may communicate with the outside world. As such, the middlebox forms the boundary between in and out, and so in and out may be measured relative to the middlebox. AFAIK, midcom allows an *agent* to be on any side of the middlebox, i.e. in or out. I don't think the relationship between the agent and the middlebox serves in any way to define what is in and what is out. >Or, do you mean networks which share a single address space but are only >connected through the middlebox functioning as a router, and are thus >all "inside" from the point of view of each other? I think I'll dismiss >that one, since it doesn't involve the middlebox NAT function. > >Assuming you mean the former ... Yes. >There was a little section that mentioned this (rummage rummage ...) >Section 9. We didn't put any detail in there -- I thought it would be a >distraction. Yes, you could make multiple virtual middleboxes out of >them, but you can theoretically also use the informant address >technique, as follows. > >It doesn't matter which of the networks the agent and clients are in, >the agent and NAT behavior are the same. In fact let's even assume the >worst case, that there are (at least) three overlapping address spaces, >all connected by one NAT, for symmetry. From the point of view of the >agent, all addressing realms except its own are "outside". > >If you're just setting up open admission, for example to receive calls, >and you're accepting connections from outside of your addressing realm, >then you don't care where from -- so you just say "outside okay", and >the NAT does not need to distinguish between those outside realms -- >when packets come in on any interface it will create a locally unique >address for whoever sent them, and know the reverse transform. > >If you're setting up a specific rule, either for an address or an >address range in a particular foreign addressing realm, then you must >have acquired a target address (or address range) for that specific rule >somewhere -- say from a SIP invitation or DNS -- and so you must already >have a unique address for an informant, already allocated by the NAT. >Given your informant address the NAT will know what to do, just as it >knows what to do for incoming packets in the previous paragraph. > >Did I miss anything? Well, maybe. I don't understand how this would work: Suppose a midcom agent is "inside" one of the multiple, overlapping, private-address domains served by a NAT middlebox. And that agent queries the mb to ask it "What public address/port pair is 10.0.0.1 tcp port 23 bound to?". Since there may be a different answer to that query for each private domain supported by the mb, the mb needs to figure out which one to return. One way it could do this is by observing which realm the midcom query was received from. Or do you think the draft offers another way? >If your mapping for the informant was provided by one middlebox and your >data is going to go through a different one, you run into discovery >problems. I think this issue is common to both proposed solutions, >although it manifests itself differently in each. I suppose we need to >make sure we're not requiring too much of discovery. Let's do that in >another thread. > >..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 12:12:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21057 for ; Fri, 14 Sep 2001 12:12: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 MAA03659; Fri, 14 Sep 2001 12:07: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 MAA03629 for ; Fri, 14 Sep 2001 12:07:03 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20923 for ; Fri, 14 Sep 2001 12:07:31 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SXH3L3ZK; Fri, 14 Sep 2001 12:06:31 -0400 Message-Id: <3.0.5.32.20010914120538.0094c7f0@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 14 Sep 2001 12:05:38 -0400 To: Adina Simu From: Mark Duffy Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt Cc: Scott Brim , midcom@ietf.org In-Reply-To: <3BA18838.BE176E4B@cisco.com> References: <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <3.0.5.32.20010913235342.00835b00@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org >The idea behind the informant address is very basic: suppose a >pre-midcom network, where ALG reside on the NAT box. When NAT has to >translate an embedded address, it figures out the topology information >(the realm where the address was originated and where is it going) from >the IP addresses in the header. An agent should provide the same info to >a middlebox doing NAT. Ah! And there is the crux of the matter. "An agent should provide the same info to a middlebox doing NAT." We have ~2 proposals on the table for *how* the agent expresses that info: by naming the interface or realm to the middlebox (other drafts), or by providing IP addresses from which the middlebox must deduce the realm (Simu/Brim draft). I see pros and cons to both. Not that it it is directly relevant, but if one considers the pre-midcom case (can we call it legacy yet? :-) with ALG residing in the mb, it effectively works the first way (naming the interface or realm). The operator configures rules whose parameters include interface and direction. --Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 12:24:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAB21265 for ; Fri, 14 Sep 2001 12:24: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 MAA03944; Fri, 14 Sep 2001 12:17: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 MAA03916 for ; Fri, 14 Sep 2001 12:17:31 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21154 for ; Fri, 14 Sep 2001 12:17:58 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SXH3L35A; Fri, 14 Sep 2001 12:17:01 -0400 Message-Id: <3.0.5.32.20010914121610.00969280@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 14 Sep 2001 12:16:10 -0400 To: Scott Brim , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Re: draft-brim-midcom-inandout vs mb with no topology knowledge In-Reply-To: <20010914114305.O1556@SBRIM-W2K> References: <3.0.5.32.20010914112543.0094d510@email.quarrytech.com> <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <20010909163142.D1680@SBRIM-W2K> <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <20010913191142.A1636@SBRIM-W2K> <3.0.5.32.20010914112543.0094d510@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 11:43 AM 9/14/01 -0400, Scott Brim wrote: >The worst case you're describing is a complex private network, with >routers, on one side, and the public network on the other side, while >the device in the middle has no knowledge whatsoever -- it's just a >firewall with whatever holes are explicitly punched through. I think >you're right. I think we don't handle that case (unless someone can >tell me how). If the firewall had an address/mask pair configured on >the "inside" interface, even if it had nothing more, then we could. > >I hope you won't say, "Aha, I found an unusual case you can't handle, >therefore we have to use the alternative, even though it adds much more >complexity for the much more common cases". > >..Scott Well, I certainly am not saying Aha. I would say, "I am not sure how unusual this scenario is but hopefully some others on the list have a better knowledge of that than I." I am just trying to explore the pros and cons of the available approaches. -Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 12:32:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21438 for ; Fri, 14 Sep 2001 12:32: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 MAA04093; Fri, 14 Sep 2001 12:24: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 MAA04062 for ; Fri, 14 Sep 2001 12:24:38 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21308 for ; Fri, 14 Sep 2001 12:25:05 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AF4455090154; Fri, 14 Sep 2001 12:24:36 -0400 Message-ID: <011201c13d38$ad02f680$2300000a@acmepacket.com> From: "Bob Penfield" To: "Melinda Shore" , , "Mark Duffy" References: <3.0.5.32.20010910182439.00a2fc50@email.quarrytech.com> <3.0.5.32.20010914110117.00950b00@email.quarrytech.com> Subject: Re: [midcom] Terminology discussion - regroup Date: Fri, 14 Sep 2001 12:16:56 -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 When I last commented on these, we had Filter Spec and Action Spec, which I prefer to the currently proposed terms. However, like Mark, I tire of the issue. Frankly, I don't see why we cannot use simple one or two word terms that have a specific meaning in a midcom document just like other documents. For example, SIP uses the terms like session and server. Megaco uses context, termination, media, and stream. If you need to use them in another context, you just insert MIDCOM in front of them. I think we got into trouble when we started looking for terms that would be totally unambiguous in all space and time. That's my rant. I will be quite now (on this subject anyway), and will not object if the current proposal is adopted. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Mark Duffy" To: "Melinda Shore" ; Sent: Friday, September 14, 2001 11:01 AM Subject: Re: [midcom] Terminology discussion - regroup > At 10:19 AM 9/14/01 -0400, Melinda Shore wrote: > >It doesn't yet appear that we have agreement on the proposed > >terminology. Where do we stand with it? > > > >Melinda > > After a great deal of discussion on the list I posted an updated proposal > on Sep 10 which Melinda sent out again on Tue, 11 Sep 2001 09:16:46 -0400 > with a call for comments. > > My personal assesment is that: > -I myself agree with the proposal :-) but tire of the issue > -Scott Brim is satisfied with it > -I believe John LaCour and Bob Penfield are satisfied with it as they > commented on certain aspects. > -I suspect Christian is not entirely happy with it but I don't know of > specific changes he would like made. > -Suresh has some significant disagreements. He would like to see different > terms used in several cases and I believe he disagrees somehat with what > the concept of Ruleset encompasses (vs middlebox "configuration"). > -I don't recall any other input. > > If I've misrepresented anyone, I'm sure they'll speak up and my most > sincere apologies. > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 13:15: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 ESMTP id NAA22152 for ; Fri, 14 Sep 2001 13: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 MAA04662; Fri, 14 Sep 2001 12:42:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04635 for ; Fri, 14 Sep 2001 12:42:26 -0400 (EDT) Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21629 for ; Fri, 14 Sep 2001 12:42:51 -0400 (EDT) Received: from 157.54.9.108 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 14 Sep 2001 09:41:35 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Sep 2001 09:41:33 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Sep 2001 09:41:33 -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, 14 Sep 2001 09:40:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] draft-brim-midcom-inandout-00.txt Date: Fri, 14 Sep 2001 09:40:54 -0700 Message-ID: Thread-Topic: [midcom] draft-brim-midcom-inandout-00.txt Thread-Index: AcE80zP+zYR8olrQQU6GMjcX7o1TjgAaK+vg From: "Christian Huitema" To: "Mark Duffy" , "Adina Simu" Cc: "Scott Brim" , X-OriginalArrivalTime: 14 Sep 2001 16:40:55.0205 (UTC) FILETIME=[060ECD50:01C13D3C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA04636 Sender: 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 meant "forward the packet". I am talking about a middlebox with > exactly > 2 interfaces that has no idea what IP addresses are "inside" or what > addresses are "outside". It has no knowledge of topology or routing > information except that one of the interfaces connects to "inside" and > the > other to "outside". Packets received by it are processed for > middlebox > services then (assuming not dropped by the middlebox) transmitted on > whichever of its 2 interfaces the packet was not received on. I > believe > there are middleboxes of this sort. I believe such a middlebox would > be > incapable of implementing your draft since it could not determine by > examining target or informant addresses whether they resided inside or > outside. I don't know of such things, and I don't believe we have to support them anyhow. Let's keep some focus: our primary concern is NAT and firewalls, and then boxes that look them. We do not have a requirement to enable any wacko box that someone may invent. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 13:15:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22164 for ; Fri, 14 Sep 2001 13:15: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 MAA04920; Fri, 14 Sep 2001 12:59: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 MAA04888 for ; Fri, 14 Sep 2001 12:59:37 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21902 for ; Fri, 14 Sep 2001 13:00:06 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SXH3L38A; Fri, 14 Sep 2001 12:59:07 -0400 Message-Id: <3.0.5.32.20010914125813.0096be00@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 14 Sep 2001 12:58:13 -0400 To: "Christian Huitema" , "Adina Simu" From: Mark Duffy Subject: RE: [midcom] draft-brim-midcom-inandout-00.txt Cc: "Scott Brim" , 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 09:40 AM 9/14/01 -0700, Christian Huitema wrote: >> I meant "forward the packet". I am talking about a middlebox with >> exactly >> 2 interfaces that has no idea what IP addresses are "inside" or what >> addresses are "outside". It has no knowledge of topology or routing >> information except that one of the interfaces connects to "inside" and >> the >> other to "outside". Packets received by it are processed for >> middlebox >> services then (assuming not dropped by the middlebox) transmitted on >> whichever of its 2 interfaces the packet was not received on. I >> believe >> there are middleboxes of this sort. I believe such a middlebox would >> be >> incapable of implementing your draft since it could not determine by >> examining target or informant addresses whether they resided inside or >> outside. > >I don't know of such things, and I don't believe we have to support them >anyhow. Let's keep some focus: our primary concern is NAT and firewalls, >and then boxes that look them. We do not have a requirement to enable >any wacko box that someone may invent. > >-- Christian Huitema I believe that what I described is a basic legacy Fw or nat box. Perhaps my description was flawed. Do you believe then that all middleboxes of concern to midcom either: a) Have a routing table, or b) Know the prefix/mask for each of their interfaces AND are not used in topologies where the NAT/security/etc domains contain other prefixes reached via routers (and therefore unknown to the mb). It may well be true that we can assume either a or b holds true. But to me at least it is not patently obvious. - Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 13:26:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22372 for ; Fri, 14 Sep 2001 13:26: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 NAA05392; Fri, 14 Sep 2001 13:18: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 NAA05368 for ; Fri, 14 Sep 2001 13:18:31 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22203 for ; Fri, 14 Sep 2001 13:18:59 -0400 (EDT) Received: from asimu-u5.cisco.com (asimu-u5.cisco.com [128.107.162.97]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8EHI0D11678; Fri, 14 Sep 2001 10:18:00 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by asimu-u5.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA01156; Fri, 14 Sep 2001 10:18:01 -0700 (PDT) Message-ID: <3BA23BC8.8426090C@cisco.com> Date: Fri, 14 Sep 2001 10:18:00 -0700 From: Adina Simu Organization: Cisco Systems X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield CC: Scott Brim , midcom@ietf.org Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt References: <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <3BA12FD2.133E1C6@cisco.com> <000d01c13d18$02b65de0$2300000a@acmepacket.com> <20010914085054.D1556@SBRIM-W2K> <00a601c13d32$e0672600$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Please see inline Bob Penfield wrote: > > ----- Original Message ----- > From: "Scott Brim" > > > > > +-------------+ > > > > | | +------+ > > > > | Customer A | | | +---------------+ > > > > | +-----------+ | | | > > > > | 10.0.0.x | | | | | > > > > | | | | | Service | > > > > +-------------+ |Middle| | Provider | > > > > | Box +------+ | > > > > +-------------+ | | | | > > > > | | | | | 192.168.20.x | > > > > | Customer B | | | | | > > > > | +-----------+ | +---------------+ > > > > | 10.0.0.x | | | > > > > | | +------+ > > > > +-------------+ > > > > > > > > Please read the draft and/or the mail more carefully. The informant > > address will not be a 10.0.0.x address. The informant address will have > > already been mapped through the NAT, since the agent is already > > exchanging packets with it. It will be locally unique in the realm of > > the agent, e.g. 192.168.20.241. In the case of SIP, when you receive an > > invitation to 10.0.0.9, you will receive it in a packet with a source > > address of 192.168.20.241. That's your informant address. When you > > pass that back to the NAT as the informant address, since it already has > > a mapping for the informant address, the NAT will know how to resolve > > your request. You already have all the hint you need. > > I see. However, this assumes that signalling packets traverse the same > middlebox that the application entities want to put the data packets > through. > > But anyway, I think I see how this can be done, let me give an example. > Using the picture above, and assuming the midcom agent is collocated with an > application entity in SP. The NAT bindings between application entities in > A, B, and SP would need to be established before any application signaling > traffic. For example, the application entities in A and B could initiate TCP > connections to the application entity (let's call them AEs) in SP. For an > application session to be established between A and B, a signaling message > would be sent from the AE in A to the AE in SP. The AE in SP determines that > this signaling message should go to the AE in B. The signaling message > contains the private IP address in A that must be NAT'd to a public address > in SP in order to get through the middlebox. The AE in SP needs to request a > NAT binding, but what it wants is "for all packets arriving on the interface > from customer B with a destination address equal to a public address you > (the middlebox) assign, forward them to the interface to customer A and > change the destination address to this private address". Now, in order to > communicate this, it needs to send both previously established public > addresses associated with AE NAT bindings. > > Let me give some concrete values. > > - connection from AE-A to AE-SP gets 192.168.20.241 as a public address > - connection from AE-B to AE-SP gets 192.168.20.242 as a public address > > - endpoint A is 10.0.0.9 in A > > - as the signaling traverses AE-SP, AE-SP determines that AE-B is the next > hop, the midcom agent needs to get a public address for endpoint A as a > target for the data packets that will be coming from the endpoint in B > (AE-SP assumes the endpoint is in B, or beyond, because the next hop AE is > in B). The request to the middlebox would look something like this: > > Ingress Informant = 192.168.20.242 (i.e. realm B) > Incoming Source = any > Incoming Destination = pick one > Egress Informant = 192.168.20.241 (i.e. Realm A) > Outgoing Source = pick one > Outgoing Destination = 10.0.0.9 > > - The signaling going back from B to A would have a similar ruleset with the > Ingress & Egress informants swapped, and the Outgoing Destination would be a > private address in B. > > Does this seem correct? Yes it looks correct... I do have 1 question though. If the scenario you're describing is: A talks to SP, then SP decides the final destination is B, forwards the packet to B, then B and A talk, then I think you need an extra agent in either A or B. Am I right? Thanks -Adina > > (-:bob > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom -- Adina Simu Software Engineer Core IP Eng - Services & Security IOS Technologies Division Phone: 408-525-1383 _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 13:29:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22413 for ; Fri, 14 Sep 2001 13:29:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05463; Fri, 14 Sep 2001 13:23: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 NAA05436 for ; Fri, 14 Sep 2001 13:23:11 -0400 (EDT) Received: from INET-VRS-07.redmond.corp.microsoft.com ([131.107.3.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22335 for ; Fri, 14 Sep 2001 13:23:39 -0400 (EDT) Received: from 157.54.8.23 by INET-VRS-07.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 14 Sep 2001 10:22:30 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Sep 2001 10:22:30 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Sep 2001 10:22:30 -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, 14 Sep 2001 10:21:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] draft-brim-midcom-inandout-00.txt Date: Fri, 14 Sep 2001 10:21:51 -0700 Message-ID: Thread-Topic: [midcom] draft-brim-midcom-inandout-00.txt Thread-Index: AcE9PsIgm/IqHWYTRai/ruxQe4ioyAAAodOg From: "Christian Huitema" To: "Mark Duffy" , "Adina Simu" Cc: "Scott Brim" , X-OriginalArrivalTime: 14 Sep 2001 17:21:51.0877 (UTC) FILETIME=[BE593350:01C13D41] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA05437 Sender: 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 > Do you believe then that all middleboxes of concern to midcom either: > a) Have a routing table, or > b) Know the prefix/mask for each of their interfaces AND are not used > in > topologies where the NAT/security/etc domains contain other prefixes > reached via routers (and therefore unknown to the mb). Yes, I believe that. And I will go on believing until you point out a product that does not, which I doubt you can. Even if you look at the low end of the market, the boxes that sell for $100 or less, you find functionalities such as DHCP servers, which definitely imply address management. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 13:31: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 ESMTP id NAB22483 for ; Fri, 14 Sep 2001 13:30: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 NAA05561; Fri, 14 Sep 2001 13:25:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05536 for ; Fri, 14 Sep 2001 13:25:54 -0400 (EDT) Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22369 for ; Fri, 14 Sep 2001 13:26:22 -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 f8EGcXW25840; Fri, 14 Sep 2001 09:38:33 -0700 Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Sep 2001 10:24:12 -0700 Message-ID: From: John LaCour To: "'Christian Huitema'" , Mark Duffy , Adina Simu Cc: Scott Brim , midcom@ietf.org Subject: RE: [midcom] draft-brim-midcom-inandout-00.txt Date: Fri, 14 Sep 2001 10:26:21 -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 We call it 'transparent' mode when our box works this way. Its essentially a bridge with stateful packet filtering and other middlebox services but no routing or NAT. -John > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Friday, September 14, 2001 9:41 AM > To: Mark Duffy; Adina Simu > Cc: Scott Brim; midcom@ietf.org > Subject: RE: [midcom] draft-brim-midcom-inandout-00.txt > > > > I meant "forward the packet". I am talking about a middlebox with > > exactly > > 2 interfaces that has no idea what IP addresses are "inside" or what > > addresses are "outside". It has no knowledge of topology or routing > > information except that one of the interfaces connects to > "inside" and > > the > > other to "outside". Packets received by it are processed for > > middlebox > > services then (assuming not dropped by the middlebox) transmitted on > > whichever of its 2 interfaces the packet was not received on. I > > believe > > there are middleboxes of this sort. I believe such a > middlebox would > > be > > incapable of implementing your draft since it could not determine by > > examining target or informant addresses whether they > resided inside or > > outside. > > I don't know of such things, and I don't believe we have to > support them > anyhow. Let's keep some focus: our primary concern is NAT and > firewalls, > and then boxes that look them. We do not have a requirement to enable > any wacko box that someone may invent. > > -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 13:31:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22526 for ; Fri, 14 Sep 2001 13:31:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05522; Fri, 14 Sep 2001 13:24: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 NAA05488 for ; Fri, 14 Sep 2001 13:24:33 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22345 for ; Fri, 14 Sep 2001 13:25:01 -0400 (EDT) Received: from asimu-u5.cisco.com (asimu-u5.cisco.com [128.107.162.97]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8EHO2D16466; Fri, 14 Sep 2001 10:24:02 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by asimu-u5.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA01161; Fri, 14 Sep 2001 10:24:02 -0700 (PDT) Message-ID: <3BA23D32.EB7B7509@cisco.com> Date: Fri, 14 Sep 2001 10:24:02 -0700 From: Adina Simu Organization: Cisco Systems X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mark Duffy CC: Scott Brim , midcom@ietf.org Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt References: <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <3.0.5.32.20010913235342.00835b00@email.quarrytech.com> <3.0.5.32.20010914120538.0094c7f0@email.quarrytech.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 Mark Duffy wrote: > > >The idea behind the informant address is very basic: suppose a > >pre-midcom network, where ALG reside on the NAT box. When NAT has to > >translate an embedded address, it figures out the topology information > >(the realm where the address was originated and where is it going) from > >the IP addresses in the header. An agent should provide the same info to > >a middlebox doing NAT. > > Ah! And there is the crux of the matter. "An agent should provide the > same info to a middlebox doing NAT." We have ~2 proposals on the table > for *how* the agent expresses that info: by naming the interface or realm > to the middlebox (other drafts), or by providing IP addresses from which > the middlebox must deduce the realm (Simu/Brim draft). I see pros and cons > to both. > > Not that it it is directly relevant, but if one considers the pre-midcom > case (can we call it legacy yet? :-) with ALG residing in the mb, it > effectively works the first way (naming the interface or realm). The > operator configures rules whose parameters include interface and direction. Mark, you're absolutely right. But what reason do we have to propagate this info now to the agent? This is exactly the point of our proposal. Thanks -Adina > > --Mark > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom -- Adina Simu Software Engineer Core IP Eng - Services & Security IOS Technologies Division Phone: 408-525-1383 _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 13:35:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22625 for ; Fri, 14 Sep 2001 13:35:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05628; Fri, 14 Sep 2001 13:28: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 NAA05601 for ; Fri, 14 Sep 2001 13:28:40 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAB22408 for ; Fri, 14 Sep 2001 13:29:09 -0400 (EDT) Received: from asimu-u5.cisco.com (asimu-u5.cisco.com [128.107.162.97]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8EHSAD19663; Fri, 14 Sep 2001 10:28:10 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by asimu-u5.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA01165; Fri, 14 Sep 2001 10:28:10 -0700 (PDT) Message-ID: <3BA23E2A.2224D699@cisco.com> Date: Fri, 14 Sep 2001 10:28:10 -0700 From: Adina Simu Organization: Cisco Systems X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: John LaCour CC: "'Christian Huitema'" , Mark Duffy , Scott Brim , midcom@ietf.org Subject: Re: [midcom] draft-brim-midcom-inandout-00.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 John LaCour wrote: > > We call it 'transparent' mode when our box works this way. Its > essentially a bridge with stateful packet filtering and other > middlebox services but no routing or NAT. If there's no NAT, then I think there's no topology problem... Am I missing something? Thanks -Adina > > -John > > > -----Original Message----- > > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > > Sent: Friday, September 14, 2001 9:41 AM > > To: Mark Duffy; Adina Simu > > Cc: Scott Brim; midcom@ietf.org > > Subject: RE: [midcom] draft-brim-midcom-inandout-00.txt > > > > > > > I meant "forward the packet". I am talking about a middlebox with > > > exactly > > > 2 interfaces that has no idea what IP addresses are "inside" or what > > > addresses are "outside". It has no knowledge of topology or routing > > > information except that one of the interfaces connects to > > "inside" and > > > the > > > other to "outside". Packets received by it are processed for > > > middlebox > > > services then (assuming not dropped by the middlebox) transmitted on > > > whichever of its 2 interfaces the packet was not received on. I > > > believe > > > there are middleboxes of this sort. I believe such a > > middlebox would > > > be > > > incapable of implementing your draft since it could not determine by > > > examining target or informant addresses whether they > > resided inside or > > > outside. > > > > I don't know of such things, and I don't believe we have to > > support them > > anyhow. Let's keep some focus: our primary concern is NAT and > > firewalls, > > and then boxes that look them. We do not have a requirement to enable > > any wacko box that someone may invent. > > > > -- Christian Huitema -- Adina Simu Software Engineer Core IP Eng - Services & Security IOS Technologies Division Phone: 408-525-1383 _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 13:43:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22815 for ; Fri, 14 Sep 2001 13:43: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 NAA06123; Fri, 14 Sep 2001 13:38: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 NAA06097 for ; Fri, 14 Sep 2001 13:38:11 -0400 (EDT) Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22694 for ; Fri, 14 Sep 2001 13:38:38 -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 f8EGoxW26359; Fri, 14 Sep 2001 09:50:59 -0700 Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Sep 2001 10:36:38 -0700 Message-ID: From: John LaCour To: "'Adina Simu'" Cc: midcom@ietf.org Subject: RE: [midcom] draft-brim-midcom-inandout-00.txt Date: Fri, 14 Sep 2001 10:38:49 -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 You can't just say 'allow src=IP-A dst=IP-B'. A packet with the source address in the header = 'IP-A' could arrive on any interface and you probably only want to allow it to be allowed through in only one direction. So you still need to communicate direction and security realms in some manner. If you wanted to use MIDCOM to install anti-spoofing packet filtering rules how would you do that? Those rules typically contradict routing and interface configurations. I think the ability to specify explictly two realms and a vector between them is critical. -John > -----Original Message----- > From: Adina Simu [mailto:asimu@cisco.com] > Sent: Friday, September 14, 2001 10:28 AM > To: John LaCour > Cc: 'Christian Huitema'; Mark Duffy; Scott Brim; midcom@ietf.org > Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt > > > John LaCour wrote: > > > > We call it 'transparent' mode when our box works this way. Its > > essentially a bridge with stateful packet filtering and other > > middlebox services but no routing or NAT. > > If there's no NAT, then I think there's no topology problem... Am I > missing something? > > Thanks > -Adina > > > > > -John > > > > > -----Original Message----- > > > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > > > Sent: Friday, September 14, 2001 9:41 AM > > > To: Mark Duffy; Adina Simu > > > Cc: Scott Brim; midcom@ietf.org > > > Subject: RE: [midcom] draft-brim-midcom-inandout-00.txt > > > > > > > > > > I meant "forward the packet". I am talking about a > middlebox with > > > > exactly > > > > 2 interfaces that has no idea what IP addresses are > "inside" or what > > > > addresses are "outside". It has no knowledge of > topology or routing > > > > information except that one of the interfaces connects to > > > "inside" and > > > > the > > > > other to "outside". Packets received by it are processed for > > > > middlebox > > > > services then (assuming not dropped by the middlebox) > transmitted on > > > > whichever of its 2 interfaces the packet was not received on. I > > > > believe > > > > there are middleboxes of this sort. I believe such a > > > middlebox would > > > > be > > > > incapable of implementing your draft since it could not > determine by > > > > examining target or informant addresses whether they > > > resided inside or > > > > outside. > > > > > > I don't know of such things, and I don't believe we have to > > > support them > > > anyhow. Let's keep some focus: our primary concern is NAT and > > > firewalls, > > > and then boxes that look them. We do not have a > requirement to enable > > > any wacko box that someone may invent. > > > > > > -- Christian Huitema > > -- > Adina Simu > Software Engineer > Core IP Eng - Services & Security > IOS Technologies Division > Phone: 408-525-1383 > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 13:59:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23379 for ; Fri, 14 Sep 2001 13:59: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 NAA06381; Fri, 14 Sep 2001 13:54: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 NAA06352 for ; Fri, 14 Sep 2001 13:54:02 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23182 for ; Fri, 14 Sep 2001 13:54:31 -0400 (EDT) Received: from asimu-u5.cisco.com (asimu-u5.cisco.com [128.107.162.97]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8EHrWD09161; Fri, 14 Sep 2001 10:53:32 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by asimu-u5.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA01190; Fri, 14 Sep 2001 10:53:32 -0700 (PDT) Message-ID: <3BA2441C.FA397C7C@cisco.com> Date: Fri, 14 Sep 2001 10:53:32 -0700 From: Adina Simu Organization: Cisco Systems X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: John LaCour CC: midcom@ietf.org Subject: Re: [midcom] draft-brim-midcom-inandout-00.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 John LaCour wrote: > > You can't just say 'allow src=IP-A dst=IP-B'. A packet > with the source address in the header = 'IP-A' could arrive > on any interface and you probably only want to allow it to be > allowed through in only one direction. So you still need to > communicate direction and security realms in some manner. > > If you wanted to use MIDCOM to install anti-spoofing packet filtering > rules how would you do that? Those rules typically contradict > routing and interface configurations. > > I think the ability to specify explictly two realms and a vector > between them is critical. I see your point... we agree that the realms have to be specified... but you're saying that specifiying them by using IP addresses is not good enough for a FW... Let me think about it for a while. -Adina > > -John > > > -----Original Message----- > > From: Adina Simu [mailto:asimu@cisco.com] > > Sent: Friday, September 14, 2001 10:28 AM > > To: John LaCour > > Cc: 'Christian Huitema'; Mark Duffy; Scott Brim; midcom@ietf.org > > Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt > > > > > > John LaCour wrote: > > > > > > We call it 'transparent' mode when our box works this way. Its > > > essentially a bridge with stateful packet filtering and other > > > middlebox services but no routing or NAT. > > > > If there's no NAT, then I think there's no topology problem... Am I > > missing something? > > > > Thanks > > -Adina > > > > > > > > -John > > > > > > > -----Original Message----- > > > > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > > > > Sent: Friday, September 14, 2001 9:41 AM > > > > To: Mark Duffy; Adina Simu > > > > Cc: Scott Brim; midcom@ietf.org > > > > Subject: RE: [midcom] draft-brim-midcom-inandout-00.txt > > > > > > > > > > > > > I meant "forward the packet". I am talking about a > > middlebox with > > > > > exactly > > > > > 2 interfaces that has no idea what IP addresses are > > "inside" or what > > > > > addresses are "outside". It has no knowledge of > > topology or routing > > > > > information except that one of the interfaces connects to > > > > "inside" and > > > > > the > > > > > other to "outside". Packets received by it are processed for > > > > > middlebox > > > > > services then (assuming not dropped by the middlebox) > > transmitted on > > > > > whichever of its 2 interfaces the packet was not received on. I > > > > > believe > > > > > there are middleboxes of this sort. I believe such a > > > > middlebox would > > > > > be > > > > > incapable of implementing your draft since it could not > > determine by > > > > > examining target or informant addresses whether they > > > > resided inside or > > > > > outside. > > > > > > > > I don't know of such things, and I don't believe we have to > > > > support them > > > > anyhow. Let's keep some focus: our primary concern is NAT and > > > > firewalls, > > > > and then boxes that look them. We do not have a > > requirement to enable > > > > any wacko box that someone may invent. > > > > > > > > -- Christian Huitema > > > > -- > > Adina Simu > > Software Engineer > > Core IP Eng - Services & Security > > IOS Technologies Division > > Phone: 408-525-1383 > > -- Adina Simu Software Engineer Core IP Eng - Services & Security IOS Technologies Division Phone: 408-525-1383 _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 14:22: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 ESMTP id OAA23965 for ; Fri, 14 Sep 2001 14:22: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 OAA07284; Fri, 14 Sep 2001 14:15: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 OAA07206 for ; Fri, 14 Sep 2001 14:15:24 -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 ESMTP id OAA23854 for ; Fri, 14 Sep 2001 14:15:52 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id CC37883A7 for ; Fri, 14 Sep 2001 13:15:20 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id NAA26155 for ; Fri, 14 Sep 2001 13:15:20 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Fri, 14 Sep 2001 13:15:20 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] draft-brim-midcom-inandout-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Fri, 14 Sep 2001, Christian Huitema wrote: > > Do you believe then that all middleboxes of concern to midcom either: > > a) Have a routing table, or > > b) Know the prefix/mask for each of their interfaces AND are not used > > in > > topologies where the NAT/security/etc domains contain other prefixes > > reached via routers (and therefore unknown to the mb). > > Yes, I believe that. And I will go on believing until you point out a > product that does not, which I doubt you can. Even if you look at the > low end of the market, the boxes that sell for $100 or less, you find > functionalities such as DHCP servers, which definitely imply address > management. http://www.aravox.com and, apparently, http://www.netscreen.com. Sun used to and possibly still does build a firewall that worked like this. I am quite certain this is an extremely partial list. See also "bridge", a.k.a. "layer 2 switch." Sure you, of all people Christian, see the value of letting routers route, security devices do security, and NAT devices do NAT, with as little overlap in functionality as possible? _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 14:33:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24205 for ; Fri, 14 Sep 2001 14:33: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 OAA07519; Fri, 14 Sep 2001 14:26: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 OAA07483 for ; Fri, 14 Sep 2001 14:26:11 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24028 for ; Fri, 14 Sep 2001 14:26:39 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id ABBE723D0146; Fri, 14 Sep 2001 14:26:06 -0400 Message-ID: <001101c13d49$8e94ade0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Adina Simu" Cc: "Scott Brim" , References: <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <3BA12FD2.133E1C6@cisco.com> <000d01c13d18$02b65de0$2300000a@acmepacket.com> <20010914085054.D1556@SBRIM-W2K> <00a601c13d32$e0672600$2300000a@acmepacket.com> <3BA23BC8.8426090C@cisco.com> Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt Date: Fri, 14 Sep 2001 14:17:46 -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: "Adina Simu" To: "Bob Penfield" Cc: "Scott Brim" ; Sent: Friday, September 14, 2001 1:18 PM Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt > Please see inline > > Bob Penfield wrote: > > > > ----- Original Message ----- > > From: "Scott Brim" > > > > > > > +-------------+ > > > > > | | +------+ > > > > > | Customer A | | | +---------------+ > > > > > | +-----------+ | | | > > > > > | 10.0.0.x | | | | | > > > > > | | | | | Service | > > > > > +-------------+ |Middle| | Provider | > > > > > | Box +------+ | > > > > > +-------------+ | | | | > > > > > | | | | | 192.168.20.x | > > > > > | Customer B | | | | | > > > > > | +-----------+ | +---------------+ > > > > > | 10.0.0.x | | | > > > > > | | +------+ > > > > > +-------------+ > > > > > > > > > > > Please read the draft and/or the mail more carefully. The informant > > > address will not be a 10.0.0.x address. The informant address will have > > > already been mapped through the NAT, since the agent is already > > > exchanging packets with it. It will be locally unique in the realm of > > > the agent, e.g. 192.168.20.241. In the case of SIP, when you receive an > > > invitation to 10.0.0.9, you will receive it in a packet with a source > > > address of 192.168.20.241. That's your informant address. When you > > > pass that back to the NAT as the informant address, since it already has > > > a mapping for the informant address, the NAT will know how to resolve > > > your request. You already have all the hint you need. > > > > I see. However, this assumes that signalling packets traverse the same > > middlebox that the application entities want to put the data packets > > through. > > > > But anyway, I think I see how this can be done, let me give an example. > > Using the picture above, and assuming the midcom agent is collocated with an > > application entity in SP. The NAT bindings between application entities in > > A, B, and SP would need to be established before any application signaling > > traffic. For example, the application entities in A and B could initiate TCP > > connections to the application entity (let's call them AEs) in SP. For an > > application session to be established between A and B, a signaling message > > would be sent from the AE in A to the AE in SP. The AE in SP determines that > > this signaling message should go to the AE in B. The signaling message > > contains the private IP address in A that must be NAT'd to a public address > > in SP in order to get through the middlebox. The AE in SP needs to request a > > NAT binding, but what it wants is "for all packets arriving on the interface > > from customer B with a destination address equal to a public address you > > (the middlebox) assign, forward them to the interface to customer A and > > change the destination address to this private address". Now, in order to > > communicate this, it needs to send both previously established public > > addresses associated with AE NAT bindings. > > > > Let me give some concrete values. > > > > - connection from AE-A to AE-SP gets 192.168.20.241 as a public address > > - connection from AE-B to AE-SP gets 192.168.20.242 as a public address > > > > - endpoint A is 10.0.0.9 in A > > > > - as the signaling traverses AE-SP, AE-SP determines that AE-B is the next > > hop, the midcom agent needs to get a public address for endpoint A as a > > target for the data packets that will be coming from the endpoint in B > > (AE-SP assumes the endpoint is in B, or beyond, because the next hop AE is > > in B). The request to the middlebox would look something like this: > > > > Ingress Informant = 192.168.20.242 (i.e. realm B) > > Incoming Source = any > > Incoming Destination = pick one > > Egress Informant = 192.168.20.241 (i.e. Realm A) > > Outgoing Source = pick one > > Outgoing Destination = 10.0.0.9 > > > > - The signaling going back from B to A would have a similar ruleset with the > > Ingress & Egress informants swapped, and the Outgoing Destination would be a > > private address in B. > > > > Does this seem correct? > > Yes it looks correct... I do have 1 question though. If the scenario > you're describing is: A talks to SP, then SP decides the final > destination is B, forwards the packet to B, then B and A talk, then I > think you need an extra agent in either A or B. Am I right? > If you mean a midcom agent, then the answer is no. In this scenario, the service provider owns the middlebox. There is only one midcom agent which is co-located with the application entity in the service provider network (AE-SP). There could be midcom agents in either A or B, but it is not required. (-:bob _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 16:28:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26040 for ; Fri, 14 Sep 2001 16:28: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 QAA10426; Fri, 14 Sep 2001 16:20: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 QAA10398 for ; Fri, 14 Sep 2001 16:19:59 -0400 (EDT) Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25949 for ; Fri, 14 Sep 2001 16:20:25 -0400 (EDT) Received: from 157.54.9.100 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 14 Sep 2001 13:17:56 -0700 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); Fri, 14 Sep 2001 13:17:56 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Sep 2001 13:17:55 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Sep 2001 13:17:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] draft-brim-midcom-inandout-00.txt Date: Fri, 14 Sep 2001 13:17:17 -0700 Message-ID: Thread-Topic: [midcom] draft-brim-midcom-inandout-00.txt Thread-Index: AcE9T5vyF5L/LfyESuqgqnThn0oWeAACdgTQ From: "Christian Huitema" To: "Andrew Molitor" , X-OriginalArrivalTime: 14 Sep 2001 20:17:17.0969 (UTC) FILETIME=[40636010:01C13D5A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA10399 Sender: 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 > http://www.aravox.com and, apparently, http://www.netscreen.com. > Sun used to and possibly still does build a firewall that worked like > this. I am quite certain this is an extremely partial list. The netscreen box can be configured to act transparently, but it definitely has the concept of inside and outside -- that is quite important for firewalls... And a Sun computer running Solaris certainly knows how to identify interfaces. > See also "bridge", a.k.a. "layer 2 switch." These are not part of the MIDCOM charter, AFAIK. > Sure you, of all people Christian, see the value of letting > routers route, security devices do security, and NAT devices do > NAT, with as little overlap in functionality as possible? Actually, I don't see the value of boxes in the middle of the network that do anything else than routing. A NAT is fundamentally a router, albeit a pervert one. The purpose of midcom is to obtain connectivity despite those critters, not to encourage their proliferation. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 17:40:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26917 for ; Fri, 14 Sep 2001 17:40: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 RAA12034; Fri, 14 Sep 2001 17:28:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12003 for ; Fri, 14 Sep 2001 17:28:53 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26800 for ; Fri, 14 Sep 2001 17:29:20 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SXH3LQPP; Fri, 14 Sep 2001 17:28:22 -0400 Message-Id: <3.0.5.32.20010914172730.00829930@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 14 Sep 2001 17:27:30 -0400 To: "Christian Huitema" , "Andrew Molitor" , From: Mark Duffy Subject: RE: [midcom] draft-brim-midcom-inandout-00.txt 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 01:17 PM 9/14/01 -0700, Christian Huitema wrote: >> http://www.aravox.com and, apparently, http://www.netscreen.com. >> Sun used to and possibly still does build a firewall that worked like >> this. I am quite certain this is an extremely partial list. > >The netscreen box can be configured to act transparently, but it >definitely has the concept of inside and outside -- that is quite >important for firewalls... And a Sun computer running Solaris certainly >knows how to identify interfaces. Please recall that this discussion was not about middleboxes distinguishing inside from outside or identifying interfaces. It was about whether one can assume that middleboxes understand network topology to the extent that they can determine whether a given IP address is inside or outside. I understood the statements from Andrew and John to mean that these middleboxes, in at least some mode, do not understand network topology to that extent. > >> See also "bridge", a.k.a. "layer 2 switch." > >These are not part of the MIDCOM charter, AFAIK. I understood that to be a reference not to a plain L2 switch, but to a middlebox embedded in one. E.g. a firewall that makes its forwarding decision based on MAC address. I do not see anything in the charter that excludes that, nor do I see any reason why it should be excluded. Midcom shouldn't care. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 17:40: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 ESMTP id RAA26929 for ; Fri, 14 Sep 2001 17:40: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 RAA11989; Fri, 14 Sep 2001 17:27: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 RAA11958 for ; Fri, 14 Sep 2001 17:27:29 -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 ESMTP id RAA26789 for ; Fri, 14 Sep 2001 17:27:55 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id 33A3583D5 for ; Fri, 14 Sep 2001 16:27:28 -0500 (CDT) Received: from localhost (amolitor@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id QAA09791 for ; Fri, 14 Sep 2001 16:27:24 -0500 (CDT) X-Authentication-Warning: isis.visi.com: amolitor owned process doing -bs Date: Fri, 14 Sep 2001 16:27:23 -0500 (CDT) From: Andrew Molitor To: midcom@ietf.org Subject: RE: [midcom] draft-brim-midcom-inandout-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Fri, 14 Sep 2001, Christian Huitema wrote: > > http://www.aravox.com and, apparently, http://www.netscreen.com. > > Sun used to and possibly still does build a firewall that worked like > > this. I am quite certain this is an extremely partial list. > > The netscreen box can be configured to act transparently, but it > definitely has the concept of inside and outside -- that is quite > important for firewalls... And a Sun computer running Solaris certainly > knows how to identify interfaces. Anything pretending to be a security device of course must know the difference between one interface and another. This is quite different from having an IP address and netmask assigned to the interface, and is quite different from knowing about IP routing in any way shape or form. We call our interfaces "Open" and "Secure" and perfectly well know the difference between them even when we're running in our transparent mode. The Sun box I referred to didn't (doesn't?) run Solaris, it was a multi-port bridge with some security features, implemented on a SPARC platform. Was this their SKIP (VPN) box? Memory fails me. > > See also "bridge", a.k.a. "layer 2 switch." > > These are not part of the MIDCOM charter, AFAIK. Fair point! However, people have built and continue to build security devices which are, viewed as network elements, bridges. People like, say, me. > > Actually, I don't see the value of boxes in the middle of the network > that do anything else than routing. A NAT is fundamentally a router, > albeit a pervert one. The purpose of midcom is to obtain connectivity > despite those critters, not to encourage their proliferation. > We'll have to disagree on this, it seems. Regardless of philosophy, if MIDCOM is built in such a way as to prevent its use on bridge-like devices, on devices which do not perform IP routing, it will be far less useful. If the WG elects to ignore this class of devices and their vendors, so be it. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 14 20:22:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28448 for ; Fri, 14 Sep 2001 20:22: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 UAA15365; Fri, 14 Sep 2001 20:15:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA15335 for ; Fri, 14 Sep 2001 20:15:21 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28398 for ; Fri, 14 Sep 2001 20:15:49 -0400 (EDT) Received: from asimu-u5.cisco.com (asimu-u5.cisco.com [128.107.162.97]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f8F0Epx29963; Fri, 14 Sep 2001 17:14:51 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by asimu-u5.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA01342; Fri, 14 Sep 2001 17:14:50 -0700 (PDT) Message-ID: <3BA29D7A.E4546738@cisco.com> Date: Fri, 14 Sep 2001 17:14:50 -0700 From: Adina Simu Organization: Cisco Systems X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mark Duffy CC: Christian Huitema , Andrew Molitor , midcom@ietf.org Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt References: <3.0.5.32.20010914172730.00829930@email.quarrytech.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 Mark Duffy wrote: > > At 01:17 PM 9/14/01 -0700, Christian Huitema wrote: > >> http://www.aravox.com and, apparently, http://www.netscreen.com. > >> Sun used to and possibly still does build a firewall that worked like > >> this. I am quite certain this is an extremely partial list. > > > >The netscreen box can be configured to act transparently, but it > >definitely has the concept of inside and outside -- that is quite > >important for firewalls... And a Sun computer running Solaris certainly > >knows how to identify interfaces. > > Please recall that this discussion was not about middleboxes distinguishing > inside from outside or identifying interfaces. It was about whether one > can assume that middleboxes understand network topology to the extent that > they can determine whether a given IP address is inside or outside. I > understood the statements from Andrew and John to mean that these > middleboxes, in at least some mode, do not understand network topology to > that extent. > > > > >> See also "bridge", a.k.a. "layer 2 switch." > > > >These are not part of the MIDCOM charter, AFAIK. > > I understood that to be a reference not to a plain L2 switch, but to a > middlebox embedded in one. E.g. a firewall that makes its forwarding > decision based on MAC address. I do not see anything in the charter that If this device doesn't use IP for addressing, why would it care about embedded IP addresses? > excludes that, nor do I see any reason why it should be excluded. Midcom > shouldn't care. This will lead us to have multiple types of addresses (IP, MAC, etc) carried by midcom... poking holes based on MAC addresses... this is a completely different issue. I thought midcom is about IP... I completely agree with Christian on this. Andrew, could you please give a config example for such a layer 2 box? I'm trying to understand how you do/configure ALGs on it. Thanks -Adina > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom -- Adina Simu Software Engineer Core IP Eng - Services & Security IOS Technologies Division Phone: 408-525-1383 _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat Sep 15 11:29:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20905 for ; Sat, 15 Sep 2001 11:29: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 LAA08028; Sat, 15 Sep 2001 11:26: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 LAA08001 for ; Sat, 15 Sep 2001 11:26: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 ESMTP id LAA20861 for ; Sat, 15 Sep 2001 11:26:28 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SXH3LRDL; Sat, 15 Sep 2001 11:26:01 -0400 Message-Id: <3.0.5.32.20010915112512.00953e40@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 15 Sep 2001 11:25:12 -0400 To: Adina Simu From: Mark Duffy Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt Cc: Christian Huitema , Andrew Molitor , midcom@ietf.org In-Reply-To: <3BA29D7A.E4546738@cisco.com> References: <3.0.5.32.20010914172730.00829930@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Adina, It is important to distinguish how the box makes its forwarding decision (where to send the packet next) from what layer(s) the middlebox function is working at. What we are talking about here is what kind of topology knowledge a middlebox might have and how it makes its forwarding decisions. At least, that is what I believe we are talking about. That a box might work at the physical or MAC layer for forwarding in no way implies that a middlebox function (e.g. firewall) within that box works off MAC addresses. -Mark (some comments embedded below too) At 05:14 PM 9/14/01 -0700, Adina Simu wrote: [snip] >> >> See also "bridge", a.k.a. "layer 2 switch." >> > >> >These are not part of the MIDCOM charter, AFAIK. >> >> I understood that to be a reference not to a plain L2 switch, but to a >> middlebox embedded in one. E.g. a firewall that makes its forwarding >> decision based on MAC address. I do not see anything in the charter that > >If this device doesn't use IP for addressing, why would it care about >embedded IP addresses? The same reason it would otherwise: for instance because it is designed to be a NAT device translating IP addresses and transport layer port numbers. It's purpose in life involves caring about IP addresses. >> excludes that, nor do I see any reason why it should be excluded. Midcom >> shouldn't care. > >This will lead us to have multiple types of addresses (IP, MAC, etc) >carried by midcom... poking holes based on MAC addresses... this is a I believe you are making an unwarranted assumption. >completely different issue. I thought midcom is about IP... I completely >agree with Christian on this. > >Andrew, could you please give a config example for such a layer 2 box? >I'm trying to understand how you do/configure ALGs on it. > >Thanks >-Adina _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Sep 16 16:32:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14382 for ; Sun, 16 Sep 2001 16:32:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26866; Sun, 16 Sep 2001 12:46:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26835 for ; Sun, 16 Sep 2001 12:46:54 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13637 for ; Sun, 16 Sep 2001 12:46:04 -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 f8GGjcD08467 for ; Sun, 16 Sep 2001 09:45:38 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-107.cisco.com [10.21.112.107]) by airborne.cisco.com (Mirapoint) with SMTP id ABA14960; Sun, 16 Sep 2001 09:45:37 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Sun, 16 Sep 2001 12:45:37 -0400 Date: Sun, 16 Sep 2001 12:45:37 -0400 From: Scott Brim To: midcom@ietf.org Message-ID: <20010916124537.I1656@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <20010909163142.D1680@SBRIM-W2K> <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <20010913191142.A1636@SBRIM-W2K> <3.0.5.32.20010914115115.00950b30@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.20010914115115.00950b30@email.quarrytech.com>; from mduffy@quarrytech.com on Fri, Sep 14, 2001 at 11:51:15AM -0400 Subject: [midcom] Re: multicontext mb and draft-brim-midcom-inandout Sender: 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 may alread be covered but for completeness ... On Fri, Sep 14, 2001 11:51:15AM -0400, Mark Duffy allegedly wrote: > Scott, comments on the 2nd part (I split the issues) --Thanks, Mark > > At 07:11 PM 9/13/01 -0400, Scott Brim wrote: > >case what you call those multiple "inside" realms would be "outside" > >to the agent. Right? The inside/outside designation doesn't have to > >do with the clients, it's in the midcom protocol, and about the > >relationship between the agent and the middlebox. > > I don't understand that, actually. I have always viewed the realms > (which we are here reducing to "in" and "out") as being an > administrative concept defined by the administrator of a realm. Since > middleboxes cost money, they are installed only when a particular need > exists such as to provide firewall to protect access to a domain, or > to provide NAT so that a private-address domain may communicate with > the outside world. As such, the middlebox forms the boundary between > in and out, and so in and out may be measured relative to the > middlebox. AFAIK, midcom allows an *agent* to be on any side of the > middlebox, i.e. in or out. I don't think the relationship between > the agent and the middlebox serves in any way to define what is in and > what is out. Words. Feh. Let me try. I think you are making "inside" synonymous with "enterprise" or something. Yes, in and out are measured relative to a middlebox, but which one is in and which is out? That depends who's looking. In the informant address scheme, inside/outside only comes up at one point -- when an agent wants to say that a particular address or range can be allowed to refer to something outside of the requesting agent's trust or address realm. We used "outside" for that meaning. If you want inside/outside to refer to something absolute in terms of middlebox configuration, as opposed to something relative to the other end of a particular midcom protocol session, I could change the name of the flag to "foreign okay" or something. > Suppose a midcom agent is "inside" one of the multiple, overlapping, > private-address domains served by a NAT middlebox. And that agent > queries the mb to ask it "What public address/port pair is 10.0.0.1 > tcp port 23 bound to?". Since there may be a different answer to that > query for each private domain supported by the mb, the mb needs to > figure out which one to return. One way it could do this is by > observing which realm the midcom query was received from. Or do you > think the draft offers another way? (1) Are foreign addresses okay? (2) What's the informant address? These two bits of information give the context in which to interpret 10.0.0.1. (Aside: the question is in error. There might not be any public address.) ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Sep 16 16:34:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14497 for ; Sun, 16 Sep 2001 16:34: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 QAA00543; Sun, 16 Sep 2001 16:33: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 QAA00514 for ; Sun, 16 Sep 2001 16:33:35 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14419 for ; Sun, 16 Sep 2001 16:32: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 f8GJpxO18776 for ; Sun, 16 Sep 2001 12:51:59 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-107.cisco.com [10.21.112.107]) by airborne.cisco.com (Mirapoint) with SMTP id ABA15313; Sun, 16 Sep 2001 12:53:57 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Sun, 16 Sep 2001 15:53:56 -0400 Date: Sun, 16 Sep 2001 15:53:56 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt Message-ID: <20010916155356.M1656@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <3BA23E2A.2224D699@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BA23E2A.2224D699@cisco.com>; from asimu@cisco.com on Fri, Sep 14, 2001 at 10:28:10AM -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 Fri, Sep 14, 2001 10:28:10AM -0700, Adina Simu allegedly wrote: > If there's no NAT, then I think there's no topology problem... Am I > missing something? Firewalls. An agent wants to be able to poke pinholes, and doesn't know what's in our out. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Sep 16 17:04:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15193 for ; Sun, 16 Sep 2001 17:04: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 RAA01324; Sun, 16 Sep 2001 17:02: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 RAA01293 for ; Sun, 16 Sep 2001 17:01:59 -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 RAA15168 for ; Sun, 16 Sep 2001 17:01:11 -0400 (EDT) Message-ID: <20010916170115.92512.qmail@web13803.mail.yahoo.com> Received: from [65.12.33.187] by web13803.mail.yahoo.com via HTTP; Sun, 16 Sep 2001 10:01:15 PDT Date: Sun, 16 Sep 2001 10:01:15 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Terminology discussion - regroup To: Bob Penfield , Melinda Shore , midcom@ietf.org, Mark Duffy In-Reply-To: <011201c13d38$ad02f680$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 It has been tiring, no doubt. Below, is a summary , as I understand, of terms that came up for discussion. - keep "Middlebox classifier rule" - Keep "Middlebox packet disposition" - Replace "Connection" with "Middlebox session" - Drop "flow", "resource" - Drop "Pinhole" - Drop "Pinhole descriptor" - Drop "Filter Spec", "Action Spec" in preference to "Middlebox classifier rule" and "Middlebox packet disposition"? - Debate over "Ruleset" vs "Configuration" - Semantics difference. Are we OK on the first seven items? MUST the debate on 8th be pursued? Melinda or Scott - Could one of you please summarize what in your mind needs done to move the framework draft through a second WG last call successfully. Thanks. cheers, suresh --- Bob Penfield wrote: > When I last commented on these, we had Filter Spec and Action Spec, which I > prefer to the currently proposed terms. However, like Mark, I tire of the > issue. Frankly, I don't see why we cannot use simple one or two word terms > that have a specific meaning in a midcom document just like other documents. > For example, SIP uses the terms like session and server. Megaco uses > context, termination, media, and stream. If you need to use them in another > context, you just insert MIDCOM in front of them. I think we got into > trouble when we started looking for terms that would be totally unambiguous > in all space and time. > > That's my rant. I will be quite now (on this subject anyway), and will not > object if the current proposal is adopted. > > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Mark Duffy" > To: "Melinda Shore" ; > Sent: Friday, September 14, 2001 11:01 AM > Subject: Re: [midcom] Terminology discussion - regroup > > > > At 10:19 AM 9/14/01 -0400, Melinda Shore wrote: > > >It doesn't yet appear that we have agreement on the proposed > > >terminology. Where do we stand with it? > > > > > >Melinda > > > > After a great deal of discussion on the list I posted an updated proposal > > on Sep 10 which Melinda sent out again on Tue, 11 Sep 2001 09:16:46 -0400 > > with a call for comments. > > > > My personal assesment is that: > > -I myself agree with the proposal :-) but tire of the issue > > -Scott Brim is satisfied with it > > -I believe John LaCour and Bob Penfield are satisfied with it as they > > commented on certain aspects. > > -I suspect Christian is not entirely happy with it but I don't know of > > specific changes he would like made. > > -Suresh has some significant disagreements. He would like to see > different > > terms used in several cases and I believe he disagrees somehat with what > > the concept of Ruleset encompasses (vs middlebox "configuration"). > > -I don't recall any other input. > > > > If I've misrepresented anyone, I'm sure they'll speak up and my most > > sincere apologies. > > > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www1.ietf.org/mailman/listinfo/midcom > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom ===== __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 17 09:29:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12132 for ; Mon, 17 Sep 2001 09:29: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 JAA29402; Mon, 17 Sep 2001 09:00: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 JAA29370 for ; Mon, 17 Sep 2001 09:00:24 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11570 for ; Mon, 17 Sep 2001 09:00:22 -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 f8HCx9D08420; Mon, 17 Sep 2001 05:59:09 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-78.cisco.com [10.82.192.78]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABA01463; Mon, 17 Sep 2001 05:59:09 -0700 (PDT) Message-Id: <5.1.0.14.0.20010917085729.00a83140@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 17 Sep 2001 09:01:00 -0400 To: Pyda Srisuresh , midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Terminology discussion - regroup In-Reply-To: <20010916170115.92512.qmail@web13803.mail.yahoo.com> References: <011201c13d38$ad02f680$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:01 AM 9/16/01 -0700, Pyda Srisuresh wrote: >Melinda or Scott - Could one of you please summarize what in your mind >needs done to move the framework draft through a second WG last call >successfully. Thanks. The first thing that ABSOLUTELY must be done is to get the terminology issues resolved and the documents aligned. The other problem is going to be the topology issue, which is going to require feedback from the ADs (I'm pursuing that). Other than that, any agreed-upon changes to the requirements need to be reflected back into the framework document. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 17 11:32: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 ESMTP id LAA14011 for ; Mon, 17 Sep 2001 11:32: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 LAA03206; Mon, 17 Sep 2001 11:19: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 LAA03177 for ; Mon, 17 Sep 2001 11:19: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 ESMTP id LAA13802 for ; Mon, 17 Sep 2001 11:19:41 -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 f8HFIhO25780 for ; Mon, 17 Sep 2001 08:18:43 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-179.cisco.com [10.21.96.179]) by airborne.cisco.com (Mirapoint) with SMTP id ABA19643; Mon, 17 Sep 2001 08:18:29 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 17 Sep 2001 11:18:33 -0400 Date: Mon, 17 Sep 2001 11:18:33 -0400 From: Scott Brim To: midcom mail-list Message-ID: <20010917111833.I1056@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom mail-list Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [midcom] new requirements bullets Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org A new version of the requirements bullets is available at . The only change since last week is the addition of R86 (allowing for more specific rulesets to override less specific ones). _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 17 17:33:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22186 for ; Mon, 17 Sep 2001 17:33: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 RAA15831; Mon, 17 Sep 2001 17:13: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 RAA15805 for ; Mon, 17 Sep 2001 17:13:02 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21973 for ; Mon, 17 Sep 2001 17:12:59 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12SNZG; Mon, 17 Sep 2001 17:11:48 -0400 Message-Id: <3.0.5.32.20010917171057.00970700@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 17 Sep 2001 17:10:57 -0400 To: Melinda Shore , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Terminology discussion - regroup In-Reply-To: <5.1.0.14.0.20010917085729.00a83140@mira-sjc5-4.cisco.com> References: <20010916170115.92512.qmail@web13803.mail.yahoo.com> <011201c13d38$ad02f680$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 09:01 AM 9/17/01 -0400, Melinda Shore wrote: ... >The first thing that ABSOLUTELY must be done is to get the >terminology issues resolved and the documents aligned. The ... >Melinda Let me try again on the terminology. As far as I can see there seems to be agreement on the definitions and on what terms to define, not define, eliminate, etc. I reiterate below. I think there is not yet agreement on the _names_ for a few terms, indicated below with ***. I suggest that we vote, roll a die, or better yet ask some disinterested party which choice they think best fits the definition and then just accept their choice. Name: *** NOT YET AGREED, HAVE THE FOLLOWING PROPOSALS: Filter Spec Classifier Rule Middlebox Classifier Rule Definition: Packet matching information that identifies a set of packets to be treated a certain way by a middlebox. Name: *** NOT YET AGREED, HAVE THE FOLLOWING PROPOSALS: Action Spec Disposition Rule Middlebox Disposition Middlebox Disposition Rule Middlebox Packet Disposition Definition: Description of the middlebox treatment/service to be applied to a set of packets. Name: *** NOT YET AGREED, HAVE THE FOLLOWING PROPOSALS: Ruleset Middlebox Configuration Parameters Definition: The combination of one or more <> and one or more <>. Packets matching the <> are to be treated as specified by the associated <>. The <> may also contain auxiliary attributes such as <> type, timeout values, creating agent, etc. Name: Midcom Session Definition: A lasting association between a MIDCOM agent and a middlebox. The MIDCOM session is not assumed to imply any specific transport layer protocol. Specifically, this should not be construed as referring to a connection-oriented TCP protocol. Pinhole -- eliminate use of this term in the documents. Pinhole-descriptor -- eliminate use of this term in the documents. (Many instances can probably be replaced with the term <>). Flow -- Resource -- Do not define these in the terminology section. Use them in their general english language sense as needed in the text. Connection -- eliminate use of this word to refer to the association between midcom agent and middlebox. Instead use the term "Midcom Session" P.S. Is it "midcom", "Midcom", "MIDCOM" or something else? It would be nice to be consistent. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 17 21:03: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 ESMTP id VAA26320 for ; Mon, 17 Sep 2001 21:03: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 UAA22638; Mon, 17 Sep 2001 20:42: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 UAA22601 for ; Mon, 17 Sep 2001 20:41:59 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26210 for ; Mon, 17 Sep 2001 20:41:58 -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 f8I0elx16117 for ; Mon, 17 Sep 2001 17:40:47 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-155.cisco.com [10.21.96.155]) by airborne.cisco.com (Mirapoint) with SMTP id ABC06151; Mon, 17 Sep 2001 17:40:44 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 17 Sep 2001 20:40:49 -0400 Date: Mon, 17 Sep 2001 20:40:48 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Terminology discussion - regroup Message-ID: <20010917204048.B1744@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <20010916170115.92512.qmail@web13803.mail.yahoo.com> <011201c13d38$ad02f680$2300000a@acmepacket.com> <5.1.0.14.0.20010917085729.00a83140@mira-sjc5-4.cisco.com> <3.0.5.32.20010917171057.00970700@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.20010917171057.00970700@email.quarrytech.com>; from mduffy@quarrytech.com on Mon, Sep 17, 2001 at 05:10:57PM -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, Sep 17, 2001 05:10:57PM -0400, Mark Duffy allegedly wrote: > At 09:01 AM 9/17/01 -0400, Melinda Shore wrote: > ... > >The first thing that ABSOLUTELY must be done is to get the > >terminology issues resolved and the documents aligned. The > ... > >Melinda > > > Let me try again on the terminology. As far as I can see there seems to be > agreement on the definitions and on what terms to define, not define, > eliminate, etc. I reiterate below. I think there is not yet agreement on > the _names_ for a few terms, indicated below with ***. I suggest that we > vote, roll a die, or better yet ask some disinterested party which choice > they think best fits the definition and then just accept their choice. > > > Name: *** NOT YET AGREED, HAVE THE FOLLOWING PROPOSALS: > Filter Spec > Classifier Rule These are close enough that it doesn't matter. > Middlebox Classifier Rule "Middlebox" is unnecessary and potentially confusing. > Definition: > Packet matching information that identifies a set of packets to be > treated a certain way by a middlebox. > > > Name: *** NOT YET AGREED, HAVE THE FOLLOWING PROPOSALS: > Action Spec > Disposition Rule OK > Middlebox Disposition > Middlebox Disposition Rule > Middlebox Packet Disposition No, same reasons :). I'm against adding "Middlebox" in general because *obviously* we're using these in the context of middleboxes -- look at the definition below, for goodness' sake -- and calling them "middlebox" things makes people wonder what other things {action specs, etc.) there might be. Are we going to have middlebox frame dispositions or something? Leave it clean and simple, the way we had it a week ago. > Definition: > Description of the middlebox treatment/service to be applied to a set > of packets. > > > Name: *** NOT YET AGREED, HAVE THE FOLLOWING PROPOSALS: > Ruleset > Middlebox Configuration Parameters If this is the only alternative to Ruleset then I'm definitely for Ruleset. Middlebox configuration parameters can be anything, for example what IP address prefixes are to be found out interface 3. Also rulesets are not necessarily installed by configuration. > Definition: > The combination of one or more <> and one or more > <>. Packets matching the <> > are to be treated as specified by the associated < rules(s)>>. The <> may also contain auxiliary attributes > such as <> type, timeout values, creating agent, etc. OK. If someone feels a need to distinguish between what is carried in the protocol and what is installed in the middlebox, the former is in-scope and the latter is not, so we are only creating a definition for what goes into the protocol. > Name: Midcom Session > Definition: > A lasting association between a MIDCOM agent and a middlebox. The > MIDCOM session is not assumed to imply any specific transport layer > protocol. Specifically, this should not be construed as referring > to a connection-oriented TCP protocol. OK > Pinhole -- > eliminate use of this term in the documents. > > Pinhole-descriptor -- > eliminate use of this term in the documents. (Many instances can > probably be replaced with the term <>). > > Flow -- > Resource -- > Do not define these in the terminology section. Use them in their > general english language sense as needed in the text. > > Connection -- > eliminate use of this word to refer to the association between > midcom agent and middlebox. Instead use the term "Midcom Session" OK > P.S. Is it "midcom", "Midcom", "MIDCOM" or something else? It would be > nice to be consistent. Aha :-). I use Midcom Working Group but the midcom protocol. "midcom" is an abbreviation but it's not made up of the first letters of its full name, so I don't like to capitalize it completely, like BGP or SIP or HIP. If you're not going to capitalize it completely then the only alternative is not to capitalize it at all. I'm trying to think of another protocol whose name is constructed like this. Y'know what, it doesn't matter much, because the next WG is going to specify it as an extension of an existing protocol anyway. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 18 09:14:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19437 for ; Tue, 18 Sep 2001 09:14: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 IAA17439; Tue, 18 Sep 2001 08:54: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 IAA17410 for ; Tue, 18 Sep 2001 08:54:42 -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 IAA19236 for ; Tue, 18 Sep 2001 08:54:40 -0400 (EDT) Message-ID: <20010918125400.73130.qmail@web13808.mail.yahoo.com> Received: from [65.12.33.187] by web13808.mail.yahoo.com via HTTP; Tue, 18 Sep 2001 05:54:00 PDT Date: Tue, 18 Sep 2001 05:54:00 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Terminology discussion - regroup To: Melinda Shore , midcom@ietf.org In-Reply-To: <5.1.0.14.0.20010917085729.00a83140@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 OK. That is in line with my thinking. Thanks. regards, suresh --- Melinda Shore wrote: > At 10:01 AM 9/16/01 -0700, Pyda Srisuresh wrote: > > >Melinda or Scott - Could one of you please summarize what in your mind > >needs done to move the framework draft through a second WG last call > >successfully. Thanks. > > The first thing that ABSOLUTELY must be done is to get the > terminology issues resolved and the documents aligned. The > other problem is going to be the topology issue, which is > going to require feedback from the ADs (I'm pursuing that). > Other than that, any agreed-upon changes to the requirements > need to be reflected back into the framework document. > > Melinda > > ===== __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 18 09:29:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19636 for ; Tue, 18 Sep 2001 09:29: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 IAA17482; Tue, 18 Sep 2001 08:55: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 IAA17453 for ; Tue, 18 Sep 2001 08:55: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 ESMTP id IAA19242 for ; Tue, 18 Sep 2001 08:55:25 -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 f8ICsFx10407 for ; Tue, 18 Sep 2001 05:54:15 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-79.cisco.com [10.82.192.79]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABO05043; Tue, 18 Sep 2001 05:54:10 -0700 (PDT) Message-Id: <5.1.0.14.0.20010918084930.00a8abf0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Sep 2001 08:56:02 -0400 To: midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Terminology discussion - regroup In-Reply-To: <20010917204048.B1744@SBRIM-W2K> References: <3.0.5.32.20010917171057.00970700@email.quarrytech.com> <20010916170115.92512.qmail@web13803.mail.yahoo.com> <011201c13d38$ad02f680$2300000a@acmepacket.com> <5.1.0.14.0.20010917085729.00a83140@mira-sjc5-4.cisco.com> <3.0.5.32.20010917171057.00970700@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Okay, let's get these closed so we can move on. Many thanks to Mark and those who've been whacking away at this. It's not fun work but it's important and necessary. Name: Filter Spec (short for filter specification - "Spec" isn't a word) Definition: Packet matching information that identifies a set of packets to be treated a certain way by a middlebox. Name: Action Spec (ditto on the "spec" thing) Definition: Description of the middlebox treatment/service to be applied to a set of packets. Name: Ruleset Definition: The combination of one or more <> and one or more <>. Packets matching the <> are to be treated as specified by the associated <>. The <> may also contain auxiliary attributes such as <> type, timeout values, creating agent, etc. Name: Midcom Session Definition: A lasting association between a MIDCOM agent and a middlebox. The MIDCOM session is not assumed to imply any specific transport layer protocol. Specifically, this should not be construed as referring to a connection-oriented TCP protocol. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 18 10:34:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21178 for ; Tue, 18 Sep 2001 10:34: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 KAA19636; Tue, 18 Sep 2001 10:08: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 KAA19598 for ; Tue, 18 Sep 2001 10:08:44 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20574 for ; Tue, 18 Sep 2001 10:08: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 f8IE5RO29466 for ; Tue, 18 Sep 2001 07:05:32 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-222.cisco.com [10.21.96.222]) by airborne.cisco.com (Mirapoint) with SMTP id ABD02557; Tue, 18 Sep 2001 07:07:25 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Tue, 18 Sep 2001 10:07:31 -0400 Date: Tue, 18 Sep 2001 10:07:31 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt Message-ID: <20010918100731.A1748@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 amolitor@visi.com on Fri, Sep 14, 2001 at 04:27:23PM -0500 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This is going to be long, because I want to do a more detailed analysis realm identifiers and informant addresses. It's time we went beyond shallow discussion. As I understand the concept, realm identifiers are a local matter -- a particular middlebox decides how it wants to identify the realms connected to it. Agents are expected to communicate with middleboxes and learn what realms they are in. When an agent communicates with another agent, it learns if that agent is in the same realm or not. Based on that it decides whether to send a ruleset to a middlebox. When discussing realm identifiers I'm going to use this figure: +---R1---+ +---R2---+ +---R3---+ | | | | | | | A1A -M1- A2A -M3- | | A1B | | A2B | | A3 | | -M2- -M4- | | | | | || | +--------+ +--------+ |+--------+ | | +--R4------+ +--R5----+ | | | | | +--- A4 -M5- A5 | | | | | +----------+ +--------+ The Rs are realms, the As are agents, the Ms are middleboxes. M5 also connects three realms, at least two with overlapping address space (this is the theoretical situation that was discussed for several days). The problems with realm identifiers are: - Realm identifiers are not just a local matter. Consider ... (1) Coordination of realm identifiers of parallel middleboxes. Suppose agent A1A learns from M1 that it is in realm 42, and agent A1B learns from M2 that it is in realm 65535 (it's the same realm, but the middleboxes are naming them independently). Then when the A1A and A1B exchange invitations, they will exchange addresses for external use because they think they are in different realms. Their packets will be routed between M1 and M2, through R2 (not R1). If R1 and R2 address spaces are overlapping, then packets may inadvertently be spilled further, beyond R2. As a solution, M1 and M2 need to coordinate their realm identifiers. This problem would also occur if A2A and A2B were communicating and got their realm identifiers from M1 and M3 -- it's not limited to the case where middleboxes attach the same realms. (2) Coordination of different middleboxes in a realm. Suppose A1A learns from M1 that it is in realm 42 and A2A learns from M3 that it is in realm 65535, but M1 is calling R2 14285. Then when A1A asks for an address for communicating with realmid 65535, M1 won't know where that is. The first result is that middleboxes have to assume, by default, that any realm id they don't understand is "outside". Inadvertent openings will, without doubt, be created, through administrative merging and splitting, misconfiguration, protocol errors, whatever. The second result is that M1 will need to return a global address, not an R2-specific one (R2 might also be private). As in the previous case packets may go through a different realm, e.g. R3 because they will have global addresses. The solution is that all middleboxes associated with a realm need to be coordinated. A large ISP could have thousands of middleboxes, real or virtual. (3) Finally, multiple overlapping address spaces attached to the same NAT middlebox (this is the theoretical situation we were discussing for the last week or so). Suppose A2A is communicating, using an application layer signaling protocol, with A5. A5 received realmid 42 from M5. M4 doesn't know where that is, and unlike the previous situation, defaulting to "outside" isn't good enough, since in this (theoretical) situation M4 has interfaces to multiple realms where A5's local address and unknown realmid might be valid. When A2A asks M4 for a pinhole/translation for realmid 42, what does M4 do? Either the middlebox needs a map from realmid to interface, for all possible realm identifiers, or the client of A5 must already have been assigned a globally unique address and the middlebox needs to know enough about routing to know how to reach that address. That is, either you need global knowledge of realm identifiers or you're no better than informant addresses even with the realm identifier system. - Using realm identifiers requires coupling of application proxies and agents. Realm identifiers need to be exchanged by agents, since they are the ones speaking to the middleboxes. However, the targets which the realm identifiers point to are first discovered by application signaling. Suppose an application signaling entity and the application agent were separate. Take SIP, for example. If a SIP proxy sends an invitation with a client address, the agent needs to intercept that invitation and somehow discover the realmid of the target. The only simple way to do that is to piggyback realmid exchange with the application signaling. This makes the midcom scheme much less flexible. For example, in the Midcom WG we have often speculated about placing agents in the same device as the middlebox functions (where the current version of "agents" are now). This tight coupling makes this impossible or at least very difficult. It is architecturally wrong to require all application proxies to be agents and speak the midcom protocol. In summary using realm identifiers requires: - A system for coordinating realm identifier assignment, for both internal and external realms, among middleboxes throughout a realm (possibly configuration). This is additional management overhead and some errors will be difficult to detect. - For complex situations, a way for a middlebox to map realm identifiers to interfaces for every realm it might communicate with. - Coupling of agents and application signaling proxies, and new protocol mechanisms for exchanging realm identifiers. - Willingness to tolerate a higher possibility of security holes because middleboxes will not have the intelligence to know if a target is inside or outside and must default to believing it is outside, and configuration errors are more likely to lead to security holes than other kinds of configuration errors. The advantages of using the realmid scheme are: - It can support almost any situation. In particular it can support control of a middlebox through a NAT, and it can support middleboxes which are not configurable even when they sit between two complex routed topologies (but only when there is only one of these in a domain). - It sends queries to middleboxes less frequently, since it learns (well, some of the time) whether a target is in another realm from other devices, not the middlebox. The advantages of the informant address approach are that it adds no new infrastructure, no configuration or administration overhead, and no security holes. It depends on the middlebox for all its topological knowledge, which is architecturally clean. However, it does not work through NAT, and in the case where a simple middlebox connects two complex realms, it assumes the middlebox at least knows what address prefixes are in the realm shared by the agent and the middlebox. Being able to work through a NAT may have no value at all -- we need customer input on this. For the case where the middlebox connects a realm with multiple address prefixes, but the middlebox does not know what they are, there are alternatives to the proposed realm identifier scheme: - Have some other way for agents to discover if they are in the same realm. - Limit the use of such devices to simple cases. This may be the case today. - Use them in conjunction with more full-featured middleboxes. More general closing thoughts: The Internet has to be simple or it will be strangled by its complexity. It's not enough for a single system to be simple. There are interactions between systems such that you have to be careful what you assume or require from the underlying Internet behavior or the Internet will ossify. Especially now, when we're about to explore new possibilities in Internet architecture, we want to limit our requirements on it. Limiting what you expect from Internet behavior may require some tradeoffs. We have made such tradeoffs in the past, and Internet services have flourished despite, or more probably because of, them. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 18 10:39:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21278 for ; Tue, 18 Sep 2001 10:39: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 KAA19835; Tue, 18 Sep 2001 10:15: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 KAA19806 for ; Tue, 18 Sep 2001 10:15:39 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20820 for ; Tue, 18 Sep 2001 10:15:36 -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 f8IEEdO03654 for ; Tue, 18 Sep 2001 07:14:39 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-222.cisco.com [10.21.96.222]) by airborne.cisco.com (Mirapoint) with SMTP id ABD02618; Tue, 18 Sep 2001 07:14:25 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Tue, 18 Sep 2001 10:14:30 -0400 Date: Tue, 18 Sep 2001 10:14:30 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Terminology discussion - regroup Message-ID: <20010918101429.K1744@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <3.0.5.32.20010917171057.00970700@email.quarrytech.com> <20010916170115.92512.qmail@web13803.mail.yahoo.com> <011201c13d38$ad02f680$2300000a@acmepacket.com> <5.1.0.14.0.20010917085729.00a83140@mira-sjc5-4.cisco.com> <3.0.5.32.20010917171057.00970700@email.quarrytech.com> <20010917204048.B1744@SBRIM-W2K> <5.1.0.14.0.20010918084930.00a8abf0@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20010918084930.00a8abf0@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Tue, Sep 18, 2001 at 08:56:02AM -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 Tue, Sep 18, 2001 08:56:02AM -0400, Melinda Shore allegedly wrote: > Okay, let's get these closed so we can move on. Many thanks to > Mark and those who've been whacking away at this. It's not fun work > but it's important and necessary. > > Name: Filter Spec (short for filter specification - "Spec" isn't a > word) > Definition: > Packet matching information that identifies a set of packets to be > treated a certain way by a middlebox. > > Name: Action Spec (ditto on the "spec" thing) > Definition: > Description of the middlebox treatment/service to be applied to a set > of packets. Nicely done. > Name: Ruleset > Definition: > The combination of one or more <> and one or more > <>. Packets matching the <> > are to be treated as specified by the associated < rules(s)>>. The <> may also contain auxiliary attributes > such as <> type, timeout values, creating agent, etc. You can fill in the placeholders based on what's above. I won't quibble over rulesets "containing" attributes. :) > Name: Midcom Session > Definition: > A lasting association between a MIDCOM agent and a middlebox. The > MIDCOM session is not assumed to imply any specific transport layer > protocol. Specifically, this should not be construed as referring > to a connection-oriented TCP protocol. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 18 11:36:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23043 for ; Tue, 18 Sep 2001 11:36: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 LAA21723; Tue, 18 Sep 2001 11:09: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 LAA21695 for ; Tue, 18 Sep 2001 11:09:38 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22180 for ; Tue, 18 Sep 2001 11:09:35 -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 f8IF8cO05457 for ; Tue, 18 Sep 2001 08:08:38 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-176.cisco.com [10.21.96.176]) by airborne.cisco.com (Mirapoint) with SMTP id ABD03132; Tue, 18 Sep 2001 08:08:25 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Tue, 18 Sep 2001 11:08:30 -0400 Date: Tue, 18 Sep 2001 11:08:30 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt Message-ID: <20010918110830.O1744@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <20010918100731.A1748@SBRIM-W2K> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010918100731.A1748@SBRIM-W2K>; from swb@employees.org on Tue, Sep 18, 2001 at 10:07:31AM -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 Tue, Sep 18, 2001 10:07:31AM -0400, 'swb @ employees . org' allegedly wrote: > When discussing realm identifiers I'm going to use this figure: > > > +---R1---+ +---R2---+ +---R3---+ > | | | | | | > | A1A -M1- A2A -M3- | > | A1B | | A2B | | A3 | > | -M2- -M4- | > | | | | || | > +--------+ +--------+ |+--------+ > | > | +--R4------+ +--R5----+ > | | | | | > +--- A4 -M5- A5 | > | | | | > +----------+ +--------+ > > The Rs are realms, the As are agents, the Ms are middleboxes. M5 typo ... I meant M4, not M5. > also connects three realms, at least two with overlapping address > space (this is the theoretical situation that was discussed for > several days). _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 18 17:16:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02508 for ; Tue, 18 Sep 2001 17:16: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 RAA02709; Tue, 18 Sep 2001 17:07: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 RAA02678 for ; Tue, 18 Sep 2001 17:07:07 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02342 for ; Tue, 18 Sep 2001 17:07:04 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A747399B02E8; Tue, 18 Sep 2001 17:06:15 -0400 Message-ID: <012101c14085$25a0ae80$2300000a@acmepacket.com> From: "Bob Penfield" To: "midcom mail-list" Cc: "Scott Brim" References: <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <3BA12FD2.133E1C6@cisco.com> <000d01c13d18$02b65de0$2300000a@acmepacket.com> <20010914085054.D1556@SBRIM-W2K> <00a601c13d32$e0672600$2300000a@acmepacket.com> <3BA23BC8.8426090C@cisco.com> <001101c13d49$8e94ade0$2300000a@acmepacket.com> <3BA64C3E.1739C910@cisco.com> Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt Date: Tue, 18 Sep 2001 17:01: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 Sender: 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 do believe that the informant address scheme can work even in scenarios with multiple outside realms with overlapping addresses. In scenarios where the informant addresses are learned from the signaling streams, it does require that the signaling traverses the middlebox. In the case of two "outside" realms with potentially overlapping addresses, you would need to supply 2 informant addresses to the middlebox. Let me illustrate: 10.0.0.7 Realm A ! +----+ ! Realm SP .....|AP-A|...... ! / +----+ \ +------+A=192.168.20.241 +----+ \...|.....A|.................+-----+ |EP-A+->-------------------|-->Y | | | +----+<--------------------|<+ | |Y=192.168.20.243 |AP-SP| 10.0.0.2 | | | | | | | | | | | | - - - - - - - - - - - - - - | | | |=================|MA | | | | | | | 10.0.0.2 | | | |X=192.168.20.244 | | +----+->-------------------|>X | | | | |EP-B+<--------------------|<--+ | .........+-----+ +----+ ......|.....B|......./ 192.168.20.1 \ +----+ / +------+B=192.168.20.242 \....|AP-B|.../ ! +----+ ! 10.0.0.9 Realm B ! .../ represents the signaling messages flowing between application end points (EPs) and application proxies (APs). ==== represents the midcom messages from the midcom agent (MA) co-located with AP-SP. ---- represents the media/data flows between the application end-points (EP). For this illustration, consider Realm SP to be "inside" and Realms A and B are "outside". The signaling connections between the outside APs and the inside AP are NATed by the middlebox. A=192.168.20.241 is the inside address of AP-A. B=192.168.20.242 is the inside address of AP-B. As the signaling traverses AP-SP it knows the previous hop is AP-A and determines through some unknown location service or logic that the next hop is AP-B. At this point, the MA in AP-SP communicates with the middlebox to establish NAT X that allows packets from the terminating endpoint EP-B to flow to the originating endpoint EP-A. X would be an inside address that EP-B would use as the destination address for its packets. Packets sent to X would be NATed to EP-A's outside (private) address. Both A and B informant addresses are passed in the midcom message to tell the middlebox that packets come in the interface to A and go out the interface to B. As the signaling response from EP-B & AP-B traverse AP-SP, it determines that the next hop is AP-A and communicates with the middlebox to establish NAT Y which allows packets to flow from EP-A to EP-B. Y is an inside address that EP-A sends data packets to which get NATed to EP-B's private address. If an informant address is used for both the egress and ingress realms, then it does not matter how many "outsides" are connected to the middlebox. As long as you have an inside address known to the midcom agent that the middlebox has mapped to the outside realm, it will work. If the middlebox did not find a mapping for the informant address, it could tell the midcom agent that the middlebox is not needed. Now, this does assume that the signaling messages traverse the middlebox and that AP-SP learns inside addresses for the outside APs when the outside APs connect to (initiating communication with) AP-SP. These mappings (NATs for the signaling streams) would need to be established by midcom agents in realms A and B OR pre-configured into the middlebox. A single informant address will suffice when the flows go from one outside realm to the inside realm. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 18 21:07:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05730 for ; Tue, 18 Sep 2001 21:07: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 VAA09666; Tue, 18 Sep 2001 21:01: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 VAA09636 for ; Tue, 18 Sep 2001 21:01:18 -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 VAA05691 for ; Tue, 18 Sep 2001 21:01:15 -0400 (EDT) Message-ID: <20010919010035.31452.qmail@web13801.mail.yahoo.com> Received: from [66.89.112.150] by web13801.mail.yahoo.com via HTTP; Tue, 18 Sep 2001 18:00:35 PDT Date: Tue, 18 Sep 2001 18:00:35 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Terminology discussion - regroup To: Melinda Shore , midcom@ietf.org In-Reply-To: <5.1.0.14.0.20010918084930.00a8abf0@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 --- Melinda Shore wrote: > Okay, let's get these closed so we can move on. Many thanks to > Mark and those who've been whacking away at this. It's not fun work > but it's important and necessary. > > Name: Filter Spec (short for filter specification - "Spec" isn't a > word) > Definition: > Packet matching information that identifies a set of packets to be > treated a certain way by a middlebox. > I can go with this. However, if I were to pick between this and <>, I would go with the latter. > Name: Action Spec (ditto on the "spec" thing) > Definition: > Description of the middlebox treatment/service to be applied to a set > of packets. > I can go with this. But, just pick one between this and <>. not both. I am Ok with either. > Name: Ruleset > Definition: > The combination of one or more <> and one or more > <>. Packets matching the <> > are to be treated as specified by the associated < rules(s)>>. The <> may also contain auxiliary attributes > such as <> type, timeout values, creating agent, etc. > This looks better. Couple of questions below. If classification is per-packet based, how do you specify session based classification? Is it fair to assume that and will be classification criteria? If I(MIDCOM agent) were to request an Address-Binding or Port-Binding, how would that fit into the ruleset above? Is that even supposed to fit into the ruleset, considering there is no single packet or session involved? If I(MIDCOM agent) were to request for a NAT session creation with certain Address/Port-Binding, how would I do that using the <> above? > Name: Midcom Session > Definition: > A lasting association between a MIDCOM agent and a middlebox. The > MIDCOM session is not assumed to imply any specific transport layer > protocol. Specifically, this should not be construed as referring > to a connection-oriented TCP protocol. > > Melinda > regards, suresh __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 19 09:55:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02503 for ; Wed, 19 Sep 2001 09:55: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 JAA05336; Wed, 19 Sep 2001 09:44: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 JAA05306 for ; Wed, 19 Sep 2001 09:44:54 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02317 for ; Wed, 19 Sep 2001 09:44:51 -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 f8JDffO11004 for ; Wed, 19 Sep 2001 06:41:41 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-117.cisco.com [10.21.96.117]) by airborne.cisco.com (Mirapoint) with SMTP id ABE08065; Wed, 19 Sep 2001 06:43:37 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Wed, 19 Sep 2001 09:43:35 -0400 Date: Wed, 19 Sep 2001 09:43:35 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Terminology discussion - regroup Message-ID: <20010919094335.A1696@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <5.1.0.14.0.20010918084930.00a8abf0@mira-sjc5-4.cisco.com> <20010919010035.31452.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: <20010919010035.31452.qmail@web13801.mail.yahoo.com>; from srisuresh@yahoo.com on Tue, Sep 18, 2001 at 06:00:35PM -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, Sep 18, 2001 06:00:35PM -0700, Pyda Srisuresh allegedly wrote: > --- Melinda Shore wrote: > > Name: Ruleset > > Definition: > > The combination of one or more <> and one or more > > <>. Packets matching the <> > > are to be treated as specified by the associated < > rules(s)>>. The <> may also contain auxiliary attributes > > such as <> type, timeout values, creating agent, etc. > > > > This looks better. Couple of questions below. > > If classification is per-packet based, how do you specify session based > classification? Is it fair to assume that session based classification> and > will be classification criteria? Suresh has a point. Will it be possible to specify stateful rules in the midcom protocol, or can rules only be based on individual packet attributes? Will stateful inspection be limited to agents? I don't think we brought this out in the requirements. > If I(MIDCOM agent) were to request an Address-Binding or Port-Binding, > how would that fit into the ruleset above? Is that even supposed to > fit into the ruleset, considering there is no single packet or session > involved? > > If I(MIDCOM agent) were to request for a NAT session creation with > certain Address/Port-Binding, how would I do that using the <> > above? The filter spec would match one side of the binding and the action spec the other side. Functionally what does an address binding actually do? In this case, minimally, you filter for "packets destined for address foo", and the action would be "translate that to address bar". ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 19 11:08: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 ESMTP id LAA03747 for ; Wed, 19 Sep 2001 11:08: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 LAA08261; Wed, 19 Sep 2001 11:04: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 LAA08230 for ; Wed, 19 Sep 2001 11:04:03 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03672 for ; Wed, 19 Sep 2001 11:04:02 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12SRKG; Wed, 19 Sep 2001 11:02:51 -0400 Message-Id: <3.0.5.32.20010919110201.008f5430@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 19 Sep 2001 11:02:01 -0400 To: Scott Brim , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Terminology discussion - regroup In-Reply-To: <20010919094335.A1696@SBRIM-W2K> References: <20010919010035.31452.qmail@web13801.mail.yahoo.com> <5.1.0.14.0.20010918084930.00a8abf0@mira-sjc5-4.cisco.com> <20010919010035.31452.qmail@web13801.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org >> If classification is per-packet based, how do you specify session based >> classification? Is it fair to assume that > session based classification> and >> will be classification criteria? > >Suresh has a point. Will it be possible to specify stateful >rules in the midcom protocol, or can rules only be based on individual >packet attributes? Will stateful inspection be limited to agents? I >don't think we brought this out in the requirements. We had some discussion earlier on about the fact that midcom facilitates removing application intelligence from the middleboxes, but at what level does "application" begin. I believe we concluded that middleboxes are generally expected to remain aware of transport layer protocols e.g. tcp. (See http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg00663.htm l and other messages in that thread.) Therefore, I have been believing that the Action Spec will include such possible actions as - allow individual packets to pass in a certain direction (stateless) - allow tcp connection in both directions as long as initial syn flows in a certain direction (tcp-stateful) R44 covers the direction aspect. See http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg00977.htm l for a proposed requirement about the stateful behavior. -Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 19 11:29: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 ESMTP id LAA04164 for ; Wed, 19 Sep 2001 11:29: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 LAA09077; Wed, 19 Sep 2001 11:21: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 LAA09046 for ; Wed, 19 Sep 2001 11:21:26 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04043 for ; Wed, 19 Sep 2001 11:21:24 -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 f8JFKRO17004 for ; Wed, 19 Sep 2001 08:20:27 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-117.cisco.com [10.21.96.117]) by airborne.cisco.com (Mirapoint) with SMTP id ABE09082; Wed, 19 Sep 2001 08:20:12 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Wed, 19 Sep 2001 11:20:10 -0400 Date: Wed, 19 Sep 2001 11:20:09 -0400 From: Scott Brim To: midcom mail-list Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt Message-ID: <20010919112009.D1696@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom mail-list References: <3.0.5.32.20010913172847.0095c650@email.quarrytech.com> <3BA12FD2.133E1C6@cisco.com> <000d01c13d18$02b65de0$2300000a@acmepacket.com> <20010914085054.D1556@SBRIM-W2K> <00a601c13d32$e0672600$2300000a@acmepacket.com> <3BA23BC8.8426090C@cisco.com> <001101c13d49$8e94ade0$2300000a@acmepacket.com> <3BA64C3E.1739C910@cisco.com> <012101c14085$25a0ae80$2300000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <012101c14085$25a0ae80$2300000a@acmepacket.com>; from bpenfield@acmepacket.com on Tue, Sep 18, 2001 at 05:01:53PM -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 Tue, Sep 18, 2001 05:01:53PM -0400, Bob Penfield allegedly wrote: > Scott, > > I do believe that the informant address scheme can work even in scenarios > with multiple outside realms with overlapping addresses. In scenarios where > the informant addresses are learned from the signaling streams, it does > require that the signaling traverses the middlebox. In the case of two > "outside" realms with potentially overlapping addresses, you would need to > supply 2 informant addresses to the middlebox. Let me illustrate: I think you've got it. > > 10.0.0.7 Realm A ! > +----+ ! Realm SP > .....|AP-A|...... ! > / +----+ \ +------+A=192.168.20.241 > +----+ \...|.....A|.................+-----+ > |EP-A+->-------------------|-->Y | | | > +----+<--------------------|<+ | |Y=192.168.20.243 |AP-SP| > 10.0.0.2 | | | | | | > | | | | | | > - - - - - - - - - - - - - - | | | |=================|MA | > | | | | | | > 10.0.0.2 | | | |X=192.168.20.244 | | > +----+->-------------------|>X | | | | > |EP-B+<--------------------|<--+ | .........+-----+ > +----+ ......|.....B|......./ 192.168.20.1 > \ +----+ / +------+B=192.168.20.242 > \....|AP-B|.../ ! > +----+ ! > 10.0.0.9 Realm B ! > > .../ represents the signaling messages flowing between application end > points (EPs) and application proxies (APs). > > ==== represents the midcom messages from the midcom agent (MA) co-located > with AP-SP. > > ---- represents the media/data flows between the application end-points > (EP). That really is an awesome diagram. > For this illustration, consider Realm SP to be "inside" and Realms A and B > are "outside". The signaling connections between the outside APs and the > inside AP are NATed by the middlebox. A=192.168.20.241 is the inside address > of AP-A. B=192.168.20.242 is the inside address of AP-B. As the signaling > traverses AP-SP it knows the previous hop is AP-A and determines through > some unknown location service or logic that the next hop is AP-B. At this > point, the MA in AP-SP communicates with the middlebox to establish NAT X > that allows packets from the terminating endpoint EP-B to flow to the > originating endpoint EP-A. X would be an inside address that EP-B would use > as the destination address for its packets. Packets sent to X would be NATed > to EP-A's outside (private) address. Both A and B informant addresses are > passed in the midcom message to tell the middlebox that packets come in the > interface to A and go out the interface to B. Right. The infrastructure -- NAT mappings or whatever -- for the agent to communicate with the remote APs is already in place before the agent makes the midcom request. The agent already has informant addresses that work. > If an informant address is used for both the egress and ingress realms, then > it does not matter how many "outsides" are connected to the middlebox. As > long as you have an inside address known to the midcom agent that the > middlebox has mapped to the outside realm, it will work. If the middlebox > did not find a mapping for the informant address, it could tell the midcom > agent that the middlebox is not needed. > > Now, this does assume that the signaling messages traverse the middlebox and > that AP-SP learns inside addresses for the outside APs when the outside APs > connect to (initiating communication with) AP-SP. These mappings (NATs for > the signaling streams) would need to be established by midcom agents in > realms A and B OR pre-configured into the middlebox. When signaling passes through one middlebox and data through another, and you have this multiple-overlapping-address-space situation, then we might have a problem. If the NAT functions map to globally unique addresses, and routing/configuration is working properly, then you're all right -- the agent will send a request to the second NAT using *global* addresses for the informants, and that NAT will still know where they are based on ordinary routing/configuration. > A single informant address will suffice when the flows go from one outside > realm to the inside realm. In that case you still have two informant addresses but one of them will be inside. It might be the agent itself, for example if the agent is proposing a wildcard or if an address is configured statically. It might be the original client the agent is acting on behalf of, or an application proxy separate from the agent, or some internal policy server. Wherever the agent learned that target address. In this one respect the agent should be dumb. Thanks ... Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 19 12:58:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06429 for ; Wed, 19 Sep 2001 12:58: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 MAA12499; Wed, 19 Sep 2001 12:42: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 MAA12464 for ; Wed, 19 Sep 2001 12:41:59 -0400 (EDT) Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06079 for ; Wed, 19 Sep 2001 12:41:54 -0400 (EDT) Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 19 Sep 2001 09:38:57 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Sep 2001 09:21:20 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Sep 2001 09:21:20 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Sep 2001 09:21:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] draft-brim-midcom-inandout-00.txt Date: Wed, 19 Sep 2001 09:21:15 -0700 Message-ID: Thread-Topic: [midcom] draft-brim-midcom-inandout-00.txt Thread-Index: AcFBIpQZCNRdSvUyQZqxREeV28OFAwAA2yyw From: "Christian Huitema" To: "Scott Brim" , "midcom mail-list" X-OriginalArrivalTime: 19 Sep 2001 16:21:16.0007 (UTC) FILETIME=[1B443770:01C14127] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA12465 Sender: 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 > > 10.0.0.7 Realm A ! > > +----+ ! Realm SP > > .....|AP-A|...... ! > > / +----+ \ +------+A=192.168.20.241 > > +----+ \...|.....A|.................+-----+ > > |EP-A+->-------------------|-->Y | | | > > +----+<--------------------|<+ | |Y=192.168.20.243 |AP-SP| > > 10.0.0.2 | | | | | | > > | | | | | | > > - - - - - - - - - - - - - - | | | |=================|MA | > > | | | | | | > > 10.0.0.2 | | | |X=192.168.20.244 | | > > +----+->-------------------|>X | | | | > > |EP-B+<--------------------|<--+ | .........+-----+ > > +----+ ......|.....B|......./ 192.168.20.1 > > \ +----+ / +------+B=192.168.20.242 > > \....|AP-B|.../ ! > > +----+ ! > > 10.0.0.9 Realm B ! > > > > .../ represents the signaling messages flowing between application > end > > points (EPs) and application proxies (APs). > > > > ==== represents the midcom messages from the midcom agent (MA) co- > located > > with AP-SP. > > > > ---- represents the media/data flows between the application end- > points > > (EP). > > That really is an awesome diagram. What the diagram shows is that if we handle scoped addresses, any mention of addresses should be qualified with a mention of the scope. The simplest solution is to consider the declaration of the interface as part of the filter specification. For example, using a diagram, and assuming that the interface serving "realm A" is called A, a filter would be: Interface = A, Interior=10.0.0.2, Exterior=192.168.20.244 This has the advantage of being unambiguous: we refer to the packet as in crosses the interface. Note that there are two ways to provide the interface information. We can repeat it in every filter specification, or we can consider that a specific MIDCOM association is between a MIDCOM agent and a specific interface. The latter would be less verbose in the case of minimal implementations, e.g. a home gateway serving a single home. In fact, a compromise could be to assume that there is a default interface specified as part of the association, but that the default can be overridden on a command by command basis. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 19 13:52: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 ESMTP id NAA07298 for ; Wed, 19 Sep 2001 13:52: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 NAA14115; Wed, 19 Sep 2001 13:50: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 NAA14090 for ; Wed, 19 Sep 2001 13:50:08 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07241 for ; Wed, 19 Sep 2001 13:50:02 -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 f8JHmqx23288 for ; Wed, 19 Sep 2001 10:48:52 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-117.cisco.com [10.21.96.117]) by airborne.cisco.com (Mirapoint) with SMTP id ABE11780; Wed, 19 Sep 2001 10:48:44 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Wed, 19 Sep 2001 13:48:40 -0400 Date: Wed, 19 Sep 2001 13:48:40 -0400 From: Scott Brim To: midcom mail-list Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt Message-ID: <20010919134839.C908@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom mail-list 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 huitema@windows.microsoft.com on Wed, Sep 19, 2001 at 09:21:15AM -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 Wed, Sep 19, 2001 09:21:15AM -0700, Christian Huitema allegedly wrote: > What the diagram shows is that if we handle scoped addresses, any > mention of addresses should be qualified with a mention of the scope. Yes. > The simplest solution is to consider the declaration of the interface as > part of the filter specification. For example, using a diagram, and > assuming that the interface serving "realm A" is called A, a filter > would be: > Interface = A, Interior=10.0.0.2, Exterior=192.168.20.244 > This has the advantage of being unambiguous: we refer to the packet as > in crosses the interface. I thought we already determined that it would be hard for agents to know which interface to use and how to name them. But anyway ... > Note that there are two ways to provide the interface information. We > can repeat it in every filter specification, or we can consider that a > specific MIDCOM association is between a MIDCOM agent and a specific > interface. The latter would be less verbose in the case of minimal > implementations, e.g. a home gateway serving a single home. In fact, a > compromise could be to assume that there is a default interface > specified as part of the association, but that the default can be > overridden on a command by command basis. Interesting idea. Small devices like your two-interface home network box are easily handled by the inandout informant address scheme. Set the informant address to all ones and set the "outside okay" flag or not, depending on what you want to do. In order to associate a default interface with a middlebox (or an only interface), the middlebox still needs a way to specify that interface. How would the middlebox get the information it needs to do that? ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 19 14:14: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 ESMTP id OAA07586 for ; Wed, 19 Sep 2001 14:14: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 OAA14923; Wed, 19 Sep 2001 14:10:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14894 for ; Wed, 19 Sep 2001 14:10:39 -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 ESMTP id OAA07548 for ; Wed, 19 Sep 2001 14:10:34 -0400 (EDT) Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.42 2001/09/04 16:24:19 root Exp $) with SMTP id SAA28814 for ; Wed, 19 Sep 2001 18:09:49 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.42.27]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001091911091609812 ; Wed, 19 Sep 2001 11:09:16 -0700 Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Sep 2001 11:10:10 -0700 Message-ID: <10C8636AE359D4119118009027AE99870DA5DADA@FMSMSX34> From: "Durham, David" To: "'cedric.aoun@nortelnetworks.com'" , "'khchan@nortelnetworks.com'" , "'nhamer@nortelnetworks.com'" , "'rpenno@nortelnetworks.com'" , "'sanjoy@nortelnetworks.com'" , "'midcom@ietf.org'" Cc: "Sahita, Ravi" , "Fenger, Russell J" Date: Wed, 19 Sep 2001 11:09:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [midcom] RE: I-D ACTION:draft-aoun-midcom-cops-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 Hi, Some comments/questions on the subject draft: 5.1 Key Midcom Requirements MET by COPS 2. Actions on failed commands must be clearly specified (proceed or reject) and the protocol should include failure reason codes. (R61, R63) COPS uses an error object that is used to identify a particular COPS protocol error. The error sub-code field contains additional detailed client (i.e. the MIDCOM COPS client) specific error codes. [Dave] Likewise, the synchronous COPS Report message & Report-type object seems to meet this requirement rather directly. 5.2 Key Midcom Requirements NOT met by COPS 1. The protocol must allow specification of a flow identifier or pinhole by at least five tuple (R40, R45, R44). A ruleset comprises of a flow identifier and action. This requirement is easily met by the current Classifier specification of existing COPS PIBs.If necessary, existing COPS Classifiers can be extended (object inheritance) to add the new MIDCOM specific filtering parameters, or new Classifier objects can easily be defined. [Dave] This could met by the classifier, but if the purpose of the flow identifier is to identify a request to the agent from the middle box, then the COPS request-handle is an variable sized identifier that can directly represent the flow identifier and 5-tuple, or whatever else is required to uniquely identify that request state. In either case, why is this requirement NOT met? 2. The protocol should allow multiple Agents to interact simultaneously with a Middle Box and vice-versa. (R3a1, R3a2) as the MIDCOM protocol The COPS protocol does not allow several COPS servers to control the same COPS client; this is a COPS architectural issue. One possible way to meet this requirement is to have several Midcom clients on a Middle [Dave] Multiple COPS servers can control the same client, so long as each server is using a different Client-Type identified in the COPS message headers. Thus, different agents can interact simultaneously with a middle box using COPS. I believe this requirement is met already. 4. The MIDCOM protocol is a client/server protocol where the Middle Box is the server. This implicitly requires that the Midcom agent establish contact with the Middle Box. In COPS, the COPS client initiates contact, which goes against the current MIDCOM principles. [Dave] Is this just saying that the midcom terminology for client vs. server is reversed from what is defined in the RAP framework? That is, the PDP must find and contact the PEPs? 5. The Agent must be authenticated by the Middlebox as part of the registration process. (R33) COPS uses transport security mechanisms (TLS or IPSEC), therefore the requirement is met but not within the protocol. [Dave] COPS already provides a built-in security mechanism that uniquely authenticates the client and server with one another, TLS & IPSEC are just gravy (I believe the COPS over TLS document is already in queue to be RFCed) . Cheers, -Dave > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, September 18, 2001 6:33 AM > Subject: I-D ACTION:draft-aoun-midcom-cops-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : COPS applicability as the MIDCOM protocol > Author(s) : C. Aoun et al. > Filename : draft-aoun-midcom-cops-00.txt > Pages : 8 > Date : 17-Sep-01 > > This draft discusses the applicability of the COPS protocol as the > MIDCOM protocol. > It discusses the architectural similarities between COPS and Midcom > and how COPS meets most of the key requirements for the Midcom > protocol. > The COPS client for the MIDCOM protocol will be specified in > separate internet drafts. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-aoun-midcom-cops-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-aoun-midcom-cops-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-aoun-midcom-cops-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. > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 19 14:48: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 ESMTP id OAA08647 for ; Wed, 19 Sep 2001 14:48: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 OAA15701; Wed, 19 Sep 2001 14:34: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 OAA15398 for ; Wed, 19 Sep 2001 14:30: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 ESMTP id OAA07888 for ; Wed, 19 Sep 2001 14:30:09 -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 f8JIStC19633; Wed, 19 Sep 2001 11:28:56 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-37.cisco.com [10.82.192.37]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABV20589; Wed, 19 Sep 2001 11:28:22 -0700 (PDT) Message-Id: <5.1.0.14.0.20010919142806.00a424a0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 19 Sep 2001 14:30:08 -0400 To: "Durham, David" , "'cedric.aoun@nortelnetworks.com'" , "'khchan@nortelnetworks.com'" , "'nhamer@nortelnetworks.com'" , "'rpenno@nortelnetworks.com'" , "'sanjoy@nortelnetworks.com'" , "'midcom@ietf.org'" From: Melinda Shore Subject: Re: [midcom] RE: I-D ACTION:draft-aoun-midcom-cops-00.txt Cc: "Sahita, Ravi" , "Fenger, Russell J" In-Reply-To: <10C8636AE359D4119118009027AE99870DA5DADA@FMSMSX34> 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:09 AM 9/19/01 -0700, Durham, David wrote: >Hi, > >Some comments/questions on the subject draft: Because the midcom requirements document really isn't even close to done it's impossible to know whether or not a given protocol meets the requirements. Also, protocol selection is outside the charter of the current iteration of the working group. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 19 15: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 ESMTP id PAA09460 for ; Wed, 19 Sep 2001 15: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 PAA17124; Wed, 19 Sep 2001 15:32:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17092 for ; Wed, 19 Sep 2001 15:32:53 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09297 for ; Wed, 19 Sep 2001 15:32:50 -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 f8JJS8g01293; Wed, 19 Sep 2001 12:29:27 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-37.cisco.com [10.82.192.37]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABV23489; Wed, 19 Sep 2001 12:30:02 -0700 (PDT) Message-Id: <5.1.0.14.0.20010919153040.00a4bd50@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 19 Sep 2001 15:31:50 -0400 To: "Reinaldo Penno" , "'Durham, David'" , "'midcom@ietf.org'" From: Melinda Shore Subject: RE: [midcom] RE: I-D ACTION:draft-aoun-midcom-cops-00.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:27 PM 9/19/01 -0700, Reinaldo Penno wrote: >We are not selecting any protocol. We did analysis on the applicability. Regardless, it's out-of-scope for midcom. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 19 15:53: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 ESMTP id PAA09621 for ; Wed, 19 Sep 2001 15:53: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 PAA17430; Wed, 19 Sep 2001 15:44: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 PAA17399 for ; Wed, 19 Sep 2001 15:44:47 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09498 for ; Wed, 19 Sep 2001 15:44:45 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA08417 for ; Wed, 19 Sep 2001 14:43:35 -0500 (CDT) Received: from zsc4c000.us.nortel.com by smtprch2.nortel.com; Wed, 19 Sep 2001 14:36:54 -0500 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Sep 2001 12:43:12 -0700 Message-ID: From: "Reinaldo Penno" To: "'Melinda Shore'" , "'Durham, David'" , "'midcom@ietf.org'" Subject: RE: [midcom] RE: I-D ACTION:draft-aoun-midcom-cops-00.txt Date: Wed, 19 Sep 2001 12:43:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14143.507F7870" 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_01C14143.507F7870 Content-Type: text/plain; charset="iso-8859-1" Then somebody should change this piece of the charter "The focus of the working group will be the architectural framework and the requirements for the protocol between the requesting device and the middle box and the architectural framework for the interface between the middle box and the policy entity. In both cases we intend to reuse existing or in process IETF protocols if possible. " where assumptions are made on the protocol, ie, that we will reuse existing or in process IETF protocols if possible. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, September 19, 2001 12:32 PM > To: Penno, Reinaldo [SC9:T327:EXCH]; 'Durham, David'; > 'midcom@ietf.org' > Subject: RE: [midcom] RE: I-D ACTION:draft-aoun-midcom-cops-00.txt > > > At 12:27 PM 9/19/01 -0700, Reinaldo Penno wrote: > >We are not selecting any protocol. We did analysis on the > applicability. > > Regardless, it's out-of-scope for midcom. > > Melinda > > ------_=_NextPart_001_01C14143.507F7870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] RE: I-D = ACTION:draft-aoun-midcom-cops-00.txt

Then somebody should change this piece of the = charter

"The focus of the working group will be the = architectural framework and the requirements for the protocol between = the requesting device and the middle box and the architectural = framework for the interface between the middle box and the policy = entity. In both cases we intend to reuse existing or in process IETF = protocols if possible. "

where assumptions are made on the protocol, ie, that = we will reuse existing or in process IETF protocols if possible. =

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Wednesday, September 19, 2001 12:32 = PM
> To: Penno, Reinaldo [SC9:T327:EXCH]; 'Durham, = David';
> 'midcom@ietf.org'
> Subject: RE: [midcom] RE: I-D = ACTION:draft-aoun-midcom-cops-00.txt
>
>
> At 12:27 PM 9/19/01 -0700, Reinaldo Penno = wrote:
> >We are not selecting any protocol. We did = analysis on the
> applicability.
>
> Regardless, it's out-of-scope for = midcom.
>
> Melinda
>
>

------_=_NextPart_001_01C14143.507F7870-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 19 15:53: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 ESMTP id PAA09644 for ; Wed, 19 Sep 2001 15:53: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 PAA17256; Wed, 19 Sep 2001 15:36: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 PAA16714 for ; Wed, 19 Sep 2001 15:29:30 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09259 for ; Wed, 19 Sep 2001 15:29:28 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA03426 for ; Wed, 19 Sep 2001 14:28:12 -0500 (CDT) Received: from zsc4c000.us.nortel.com by smtprch2.nortel.com; Wed, 19 Sep 2001 14:21:28 -0500 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Sep 2001 12:27:47 -0700 Message-ID: From: "Reinaldo Penno" To: "'Melinda Shore'" , "'Durham, David'" , "Cedric Aoun" , "Kwok-Ho Chan" , "Louis-Nicolas Hamer" , "Sanjoy Sen" , "'midcom@ietf.org'" Cc: "'Sahita, Ravi'" , "'Fenger, Russell J'" Subject: RE: [midcom] RE: I-D ACTION:draft-aoun-midcom-cops-00.txt Date: Wed, 19 Sep 2001 12:27:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14141.27B15FA0" 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_01C14141.27B15FA0 Content-Type: text/plain; charset="iso-8859-1" Hello Melinda, > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, September 19, 2001 11:30 AM > To: Durham, David; Aoun, Cedric [QPD:MA01:EXCH]; Chan, Kwok-Ho > [BL60:470:EXCH]; Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; > Penno, Reinaldo > [SC9:T327:EXCH]; Sen, Sanjoy [NGB:B602:EXCH]; 'midcom@ietf.org' > Cc: Sahita, Ravi; Fenger, Russell J > Subject: Re: [midcom] RE: I-D ACTION:draft-aoun-midcom-cops-00.txt > > > At 11:09 AM 9/19/01 -0700, Durham, David wrote: > >Hi, > > > >Some comments/questions on the subject draft: > > Because the midcom requirements document really isn't even > close to done it's impossible to know whether or not a given > protocol meets the requirements. That's why we will update the draft as the requirements change. Also, protocol selection. > is outside the charter of the current iteration of the working > group. > We are not selecting any protocol. We did analysis on the applicability. -Reinaldo Penno > Melinda > > > ------_=_NextPart_001_01C14141.27B15FA0 Content-Type: text/html; charset="iso-8859-1" RE: [midcom] RE: I-D ACTION:draft-aoun-midcom-cops-00.txt

Hello Melinda,

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Wednesday, September 19, 2001 11:30 AM
> To: Durham, David; Aoun, Cedric [QPD:MA01:EXCH]; Chan, Kwok-Ho
> [BL60:470:EXCH]; Hamer, Louis-Nicolas [WDLN2:AN22:EXCH];
> Penno, Reinaldo
> [SC9:T327:EXCH]; Sen, Sanjoy [NGB:B602:EXCH]; 'midcom@ietf.org'
> Cc: Sahita, Ravi; Fenger, Russell J
> Subject: Re: [midcom] RE: I-D ACTION:draft-aoun-midcom-cops-00.txt
>
>
> At 11:09 AM 9/19/01 -0700, Durham, David wrote:
> >Hi,
> >
> >Some comments/questions on the subject draft:
>
> Because the midcom requirements document really isn't even
> close to done it's impossible to know whether or not a given
> protocol meets the requirements. 

That's why we will update the draft as the requirements change.

Also, protocol selection.
> is outside the charter of the current iteration of the working
> group.
>

We are not selecting any protocol. We did analysis on the applicability.

-Reinaldo Penno

> Melinda
>
>
>

------_=_NextPart_001_01C14141.27B15FA0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 19 16:01:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09857 for ; Wed, 19 Sep 2001 16:01: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 PAA17586; Wed, 19 Sep 2001 15:55: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 PAA17555 for ; Wed, 19 Sep 2001 15:55:28 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09708 for ; Wed, 19 Sep 2001 15:55:26 -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 f8JJsFu26039; Wed, 19 Sep 2001 12:54:16 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-37.cisco.com [10.82.192.37]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABV24537; Wed, 19 Sep 2001 12:53:54 -0700 (PDT) Message-Id: <5.1.0.14.0.20010919155323.00a41360@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 19 Sep 2001 15:55:41 -0400 To: "Reinaldo Penno" , "'Durham, David'" , "'midcom@ietf.org'" From: Melinda Shore Subject: RE: [midcom] RE: I-D ACTION:draft-aoun-midcom-cops-00.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:43 PM 9/19/01 -0700, Reinaldo Penno wrote: >Then somebody should change this piece of the charter > >"The focus of the working group will be the architectural framework and the requirements for the protocol between the requesting device and the middle box and the architectural framework for the interface between the middle box and the policy entity. In both cases we intend to reuse existing or in process IETF protocols if possible. " In no place does it say that we will be selecting or discussing particular protocols, and it's been absolutely, unambiguously clear from the outset that neither is within our charter. We need to get the two deliverables completed before we can start work on rechartering. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 19 16:04:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09911 for ; Wed, 19 Sep 2001 16:04: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 PAA17189; Wed, 19 Sep 2001 15:34: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 PAA17161 for ; Wed, 19 Sep 2001 15:34:38 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09308 for ; Wed, 19 Sep 2001 15:34:36 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA05166 for ; Wed, 19 Sep 2001 14:33:26 -0500 (CDT) Received: from zsc4c000.us.nortel.com by smtprch2.nortel.com; Wed, 19 Sep 2001 14:26:34 -0500 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Sep 2001 12:32:53 -0700 Message-ID: From: "Reinaldo Penno" To: "'midcom@ietf.org'" Subject: RE: [midcom] RE: I-D ACTION:draft-aoun-midcom-cops-00.txt Date: Wed, 19 Sep 2001 12:32:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14141.DF632160" 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_01C14141.DF632160 Content-Type: text/plain; charset="iso-8859-1" Hello Melinda, > > -----Original Message----- > > From: Melinda Shore [mailto:mshore@cisco.com] > > Sent: Wednesday, September 19, 2001 11:30 AM > > To: Durham, David; Aoun, Cedric [QPD:MA01:EXCH]; Chan, Kwok-Ho > > [BL60:470:EXCH]; Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; > > Penno, Reinaldo > > [SC9:T327:EXCH]; Sen, Sanjoy [NGB:B602:EXCH]; 'midcom@ietf.org' > > Cc: Sahita, Ravi; Fenger, Russell J > > Subject: Re: [midcom] RE: I-D ACTION:draft-aoun-midcom-cops-00.txt > > > > > > At 11:09 AM 9/19/01 -0700, Durham, David wrote: > > >Hi, > > > > > >Some comments/questions on the subject draft: > > > > Because the midcom requirements document really isn't even > > close to done it's impossible to know whether or not a given > > protocol meets the requirements. > That's why we will update the draft as the requirements change. > > Also, protocol selection. > > is outside the charter of the current iteration of the working > > group. > > > We are not selecting any protocol. We did analysis on the applicability. -Reinaldo Penno > > Melinda > > > > > > > ------_=_NextPart_001_01C14141.DF632160 Content-Type: text/html; charset="iso-8859-1" RE: [midcom] RE: I-D ACTION:draft-aoun-midcom-cops-00.txt

Hello Melinda,
 
> > -----Original Message-----
> > From: Melinda Shore [mailto:mshore@cisco.com]
> > Sent: Wednesday, September 19, 2001 11:30 AM
> > To: Durham, David; Aoun, Cedric [QPD:MA01:EXCH]; Chan, Kwok-Ho
> > [BL60:470:EXCH]; Hamer, Louis-Nicolas [WDLN2:AN22:EXCH];
> > Penno, Reinaldo
> > [SC9:T327:EXCH]; Sen, Sanjoy [NGB:B602:EXCH]; 'midcom@ietf.org'
> > Cc: Sahita, Ravi; Fenger, Russell J
> > Subject: Re: [midcom] RE: I-D ACTION:draft-aoun-midcom-cops-00.txt
> >
> >
> > At 11:09 AM 9/19/01 -0700, Durham, David wrote:
> > >Hi,
> > >
> > >Some comments/questions on the subject draft:
> >
> > Because the midcom requirements document really isn't even
> > close to done it's impossible to know whether or not a given
> > protocol meets the requirements. 
>

That's why we will update the draft as the requirements change.

>
> Also, protocol selection.
> > is outside the charter of the current iteration of the working
> > group.
> >
>

  We are not selecting any protocol. We did analysis on the applicability.
 
 -Reinaldo Penno
 
> > Melinda
> >
> >
> >
>

------_=_NextPart_001_01C14141.DF632160-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 19 17:24: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 ESMTP id RAA11298 for ; Wed, 19 Sep 2001 17:24: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 RAA20468; Wed, 19 Sep 2001 17:16: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 RAA20394 for ; Wed, 19 Sep 2001 17:16:34 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11216 for ; Wed, 19 Sep 2001 17:16:30 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA10196 for ; Wed, 19 Sep 2001 16:14:51 -0500 (CDT) Received: from zsc4c000.us.nortel.com by smtprch2.nortel.com; Wed, 19 Sep 2001 16:07:55 -0500 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Sep 2001 14:14:14 -0700 Message-ID: From: "Reinaldo Penno" To: "'Melinda Shore'" , "'Durham, David'" , "'midcom@ietf.org'" Subject: RE: [midcom] RE: I-D ACTION:draft-aoun-midcom-cops-00.txt Date: Wed, 19 Sep 2001 14:14:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14150.047B1990" 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_01C14150.047B1990 Content-Type: text/plain; charset="iso-8859-1" clearly this is not what I meant by my previous email, but anyway, this discussion is pointless. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, September 19, 2001 12:56 PM > To: Penno, Reinaldo [SC9:T327:EXCH]; 'Durham, David'; > 'midcom@ietf.org' > Subject: RE: [midcom] RE: I-D ACTION:draft-aoun-midcom-cops-00.txt > > > At 12:43 PM 9/19/01 -0700, Reinaldo Penno wrote: > >Then somebody should change this piece of the charter > > > >"The focus of the working group will be the architectural > framework and the requirements for the protocol between the > requesting device and the middle box and the architectural > framework for the interface between the middle box and the > policy entity. In both cases we intend to reuse existing or > in process IETF protocols if possible. " > > In no place does it say that we will be selecting or discussing > particular protocols, and it's been absolutely, unambiguously clear > from the outset that neither is within our charter. We need to get > the two deliverables completed before we can start work on > rechartering. > > Melinda > > ------_=_NextPart_001_01C14150.047B1990 Content-Type: text/html; charset="iso-8859-1" RE: [midcom] RE: I-D ACTION:draft-aoun-midcom-cops-00.txt

clearly this is not what I meant by my previous email, but anyway, this discussion is pointless.


> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Wednesday, September 19, 2001 12:56 PM
> To: Penno, Reinaldo [SC9:T327:EXCH]; 'Durham, David';
> 'midcom@ietf.org'
> Subject: RE: [midcom] RE: I-D ACTION:draft-aoun-midcom-cops-00.txt
>
>
> At 12:43 PM 9/19/01 -0700, Reinaldo Penno wrote:
> >Then somebody should change this piece of the charter
> >
> >"The focus of the working group will be the architectural
> framework and the requirements for the protocol between the
> requesting device and the middle box and the architectural
> framework for the interface between the middle box and the
> policy entity. In both cases we intend to reuse existing or
> in process IETF protocols if possible. "
>
> In no place does it say that we will be selecting or discussing
> particular protocols, and it's been absolutely, unambiguously clear
> from the outset that neither is within our charter.  We need to get
> the two deliverables completed before we can start work on
> rechartering.
>
> Melinda
>
>

------_=_NextPart_001_01C14150.047B1990-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 19 19:29:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12544 for ; Wed, 19 Sep 2001 19:29: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 TAA23159; Wed, 19 Sep 2001 19:22: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 TAA23130 for ; Wed, 19 Sep 2001 19:22:46 -0400 (EDT) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12488 for ; Wed, 19 Sep 2001 19:22:44 -0400 (EDT) Received: from 157.54.7.67 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 19 Sep 2001 16:21:25 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Sep 2001 16:21:22 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Sep 2001 16:21:22 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Sep 2001 16:21:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] draft-brim-midcom-inandout-00.txt Date: Wed, 19 Sep 2001 16:21:17 -0700 Message-ID: Thread-Topic: [midcom] draft-brim-midcom-inandout-00.txt Thread-Index: AcFBNUGVMGHEvJslQ2CWQHtqL29wAQAK9WLg From: "Christian Huitema" To: "Scott Brim" , "midcom mail-list" X-OriginalArrivalTime: 19 Sep 2001 23:21:17.0685 (UTC) FILETIME=[C8A31A50:01C14161] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA23131 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > In order to associate a default interface with a middlebox (or an only > interface), the middlebox still needs a way to specify that interface. > How would the middlebox get the information it needs to do that? I did not say that the default is associated with a middlebox; I said it should be defined for an association. This can be done in many ways. For example, in many cases the FCP will be used by a server or a peer that is already inside a "protected domain." In that case, the default interface is the one between the protected domain and the middlebox; naming can be implicit. I understand that there are "softswitch" applications that would want to control specific interfaces within a multi-interface box. These applications will probably have a somewhat intimate knowledge of the middlebox configuration, and resort to explicit naming of the interfaces. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 19 21:30:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13493 for ; Wed, 19 Sep 2001 21:30: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 VAA25412; Wed, 19 Sep 2001 21:16: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 VAA25383 for ; Wed, 19 Sep 2001 21:16: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 ESMTP id VAA13379 for ; Wed, 19 Sep 2001 21:16:35 -0400 (EDT) Received: from asimu-u5.cisco.com (asimu-u5.cisco.com [128.107.162.97]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f8K1FQc03704; Wed, 19 Sep 2001 18:15:26 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by asimu-u5.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA02049; Wed, 19 Sep 2001 18:15:25 -0700 (PDT) Message-ID: <3BA9432D.DC088007@cisco.com> Date: Wed, 19 Sep 2001 18:15:25 -0700 From: Adina Simu Organization: Cisco Systems X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema CC: Scott Brim , midcom mail-list Subject: Re: [midcom] draft-brim-midcom-inandout-00.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 Christian Huitema wrote: > > > In order to associate a default interface with a middlebox (or an only > > interface), the middlebox still needs a way to specify that interface. > > How would the middlebox get the information it needs to do that? > > I did not say that the default is associated with a middlebox; I said it > should be defined for an association. This can be done in many ways. For > example, in many cases the FCP will be used by a server or a peer that > is already inside a "protected domain." In that case, the default > interface is the one between the protected domain and the middlebox; > naming can be implicit. I understand that there are "softswitch" > applications that would want to control specific interfaces within a > multi-interface box. These applications will probably have a somewhat > intimate knowledge of the middlebox configuration, and resort to > explicit naming of the interfaces. If: - the agent uses the right informant address - the middlebox does IP routing (which should be the case if multiple interfaces are present) then the middlebox can infer the interfaces from the informant addresses. The security is okay as long as the informant address is a valid one. If that's not secure, and somebody tricks the agent into asking for pinholes to be opened... this is a different issue... Also, if the agent doesn't specify both ingress/egress realms, then the middlebox might open too much. I'm not sure the outside_okay flag is enough, from this perspective. On some FWs, there's no notion of "Inside" and "Outside". There are access lists and inspection rules applied to interfaces. Plus, in reality there are different degrees of "Inside/Outside". One possible example is: an enterprise FW with multiple interfaces, connecting several Depts, the DMZ and the Internet: Internet | Dept.A e2| Dept.B -------- endp1 10.0.0.1-| e1| |e3 |-3.3.3.1 endp2 |-----| |-----| | | | |e4 | |-----| Dept.C -------- |-7.7.7.1 endp3 |e5 | ---- DMZ | 5.5.5.1 SIP Proxy + registrar + agent I assume that all call signalling goes through the Proxy. When endp1 registers with the Proxy, no midcom interaction is needed. When somebody wants to call endp1, first it will go to the Proxy. At this point, the proxy can check the policy and decide if the call is allowed or not (eg: only endp3 can call endp1). At this point the agent is able to properly qualify both ingress and egress realms, and ask for a well defined pinhole to be opened. But this assumes that midcom is used in a specific way - when an actual call is made, not at the registration moment. I think the technique is fine, if used with precaution. ??? Is it still usable? I don't know... I think so, if both ingress/egress realms (informant addresses) are mandatory in the pinhole request. Does it make sense? -Adina > -- Christian Huitema > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom -- Adina Simu Software Engineer Core IP Eng - Services & Security IOS Technologies Division Phone: 408-525-1383 _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 20 09:47: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 ESMTP id JAA10109 for ; Thu, 20 Sep 2001 09:47: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 JAA26955; Thu, 20 Sep 2001 09:44: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 JAA26927 for ; Thu, 20 Sep 2001 09:44:57 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10020 for ; Thu, 20 Sep 2001 09:44:53 -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 f8KDfjg16214 for ; Thu, 20 Sep 2001 06:41:45 -0700 (PDT) Received: from SBRIM-W2K (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with SMTP id ABE24889; Thu, 20 Sep 2001 06:43:43 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 20 Sep 2001 09:43:37 -0400 Date: Thu, 20 Sep 2001 09:43:37 -0400 From: Scott Brim To: midcom mail-list Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt Message-ID: <20010920094336.E1936@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom mail-list References: <3BA9432D.DC088007@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BA9432D.DC088007@cisco.com>; from asimu@cisco.com on Wed, Sep 19, 2001 at 06:15:25PM -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 Wed, Sep 19, 2001 06:15:25PM -0700, Adina Simu allegedly wrote: > One possible example is: an enterprise FW with multiple interfaces, > connecting several Depts, the DMZ and the Internet: > > > Internet > | > Dept.A e2| Dept.B > -------- > endp1 10.0.0.1-| e1| |e3 |-3.3.3.1 endp2 > |-----| |-----| > | | > | |e4 > | |-----| Dept.C > -------- |-7.7.7.1 endp3 > |e5 > | > ---- DMZ > | > 5.5.5.1 > SIP Proxy + registrar + agent > > > I assume that all call signalling goes through the Proxy. > > When endp1 registers with the Proxy, no midcom interaction is needed. > When somebody wants to call endp1, first it will go to the Proxy. At > this point, the proxy can check the policy and decide if the call is > allowed or not (eg: only endp3 can call endp1). At this point the agent > is able to properly qualify both ingress and egress realms, and ask for > a well defined pinhole to be opened. > > But this assumes that midcom is used in a specific way - when an actual > call is made, not at the registration moment. Endp1 doesn't need any midcom interaction for inside calls, but in order for someone to call endp1 from outside, endp1 needs its address mapped to a globally meaningful address to start with. Thanks to the wonders of NAT, endp1 has a different address for inside and outside connections. I think your point is that when initially allowing all calls to come in, endp1 doesn't have any particular informant address for whoever it might be communicating with yet. I was assuming we could have some special bit of syntax for that, like all 0s. Yet another thing that didn't actually get put in the draft. At the registration moment, for outside calls you need to create a mapping. The source address is a wildcard * with 'outside okay' set. The informant address for the source address is all 0s. The destination address is endp1 with an informant address of endp1. The request for an action spec is for a global mapping. > I think the technique is fine, if used with precaution. ??? Is it still > usable? I don't know... I think so, if both ingress/egress realms > (informant addresses) are mandatory in the pinhole request. I think the informant address fields are always meaningful. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 20 09:52:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10289 for ; Thu, 20 Sep 2001 09:52: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 JAA27105; Thu, 20 Sep 2001 09:50: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 JAA27076 for ; Thu, 20 Sep 2001 09:50:23 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10228 for ; Thu, 20 Sep 2001 09:50:20 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id IAA16730 for ; Thu, 20 Sep 2001 08:49:11 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Thu, 20 Sep 2001 08:42:20 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 08:48:42 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F16E@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: midcom@ietf.org Cc: "Sanjoy Sen" , "Cedric Aoun" , "Tom-PT Taylor" Date: Thu, 20 Sep 2001 08:48:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C141DA.F885F890" X-Orig: Subject: [midcom] Submission of new drafts relevant to Midcom Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This 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_01C141DA.F885F890 Content-Type: text/plain; charset="iso-8859-1" All, We've submitted a couple of new drafts relevant to Midcom protocol selection. The first discusses the applicability of Megaco as the Midcom protocol & the second proposes some preliminary extensions to the base Megaco protocol in the form of new Middlebox Termination/Packages to support Midcom. Until they appear at the IETF website, they can be obtained at: www.obsidian97.com/draft-sct-midcom-megaco-00.txt www.obsidian97.com/draft-sct-midcom-megaco-pkg-00.txt THE AUTHORS RECOGNIZE THAT THIS WORK IS CURRENTLY DEEMED OUT OF SCOPE, AND THAT THE INTENT IS NOT TO DISTRACT THE WG FROM MAKING PROGRESS ON THE CURRENT WORK ITEMS. Feedback is requested to be sent to the individual authors and not the WG mailing list. The intent is to get input so that the draft can be mature enough to be discussed once this work is deemed to be relevant to the charter. The author's intend to keep the document updated against the current WG work as it is progressed. Thanks & regards, Sanjoy Sen ------_=_NextPart_001_01C141DA.F885F890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Submission of new drafts relevant to Midcom

All,

        We've = submitted a couple of new drafts relevant to Midcom protocol selection. = The first discusses the applicability of Megaco as the Midcom protocol = & the second proposes some preliminary extensions to the base = Megaco protocol in the form of new Middlebox Termination/Packages to = support Midcom. Until they appear at the IETF website, they can be = obtained at:

www.obsidian97.com/draft-sct-midcom-megaco-00.txt

www.obsidian97.com/draft-sct-midcom-megaco-pkg-00.txt

THE AUTHORS RECOGNIZE THAT THIS WORK IS CURRENTLY = DEEMED OUT OF SCOPE, AND THAT THE INTENT IS NOT TO DISTRACT THE WG FROM = MAKING PROGRESS ON THE CURRENT WORK ITEMS. Feedback is requested to be = sent to the individual authors and not the WG mailing list.  The = intent is to get input so that the draft can be mature enough to be = discussed once this work is deemed to be relevant to the = charter.   The author's intend to keep the document updated = against the current WG work as it is progressed.

Thanks & regards,

Sanjoy Sen

------_=_NextPart_001_01C141DA.F885F890-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 20 10:22: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 ESMTP id KAA11340 for ; Thu, 20 Sep 2001 10:22: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 KAA28041; Thu, 20 Sep 2001 10:18: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 KAA28014 for ; Thu, 20 Sep 2001 10:18:11 -0400 (EDT) Received: from web13804.mail.yahoo.com (web13804.mail.yahoo.com [216.136.175.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11194 for ; Thu, 20 Sep 2001 10:18:07 -0400 (EDT) Message-ID: <20010920141719.42122.qmail@web13804.mail.yahoo.com> Received: from [65.12.33.187] by web13804.mail.yahoo.com via HTTP; Thu, 20 Sep 2001 07:17:19 PDT Date: Thu, 20 Sep 2001 07:17:19 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Terminology discussion - regroup To: Scott Brim , midcom@ietf.org In-Reply-To: <20010919094335.A1696@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: > On Tue, Sep 18, 2001 06:00:35PM -0700, Pyda Srisuresh allegedly wrote: > > --- Melinda Shore wrote: > > > Name: Ruleset > > > Definition: > > > The combination of one or more <> and one or more > > > <>. Packets matching the <> > > > are to be treated as specified by the associated < > > rules(s)>>. The <> may also contain auxiliary attributes > > > such as <> type, timeout values, creating agent, etc. > > > > > > > This looks better. Couple of questions below. > > > > If classification is per-packet based, how do you specify session based > > classification? Is it fair to assume that > session based classification> and > > will be classification criteria? > > Suresh has a point. Will it be possible to specify stateful > rules in the midcom protocol, or can rules only be based on individual > packet attributes? Will stateful inspection be limited to agents? I > don't think we brought this out in the requirements. > As I understand, the intent of the ruleset definition is to be able to describe rules that may be communicated over the MIDCOM protocol. As such, defining ruleset as per-packet based is inadequate for the purpose. As for "Will stateful inspection be limited to agents?", I am not sure I understand the question. Application specific stateful processing will be with the agent. However, that would still leave application-independent per-session state management to the middlebox. > > If I(MIDCOM agent) were to request an Address-Binding or Port-Binding, > > how would that fit into the ruleset above? Is that even supposed to > > fit into the ruleset, considering there is no single packet or session > > involved? > > > > If I(MIDCOM agent) were to request for a NAT session creation with > > certain Address/Port-Binding, how would I do that using the <> > > above? > > The filter spec would match one side of the binding and the action spec > the other side. Functionally what does an address binding actually do? Address-binding, as a whole, is what you might call the action spec that dictates action for one or more sessions that use the Address-Binding. When a packet is classified as belonging to one of the NAT-managed sessions, the associated Address-binding (or Port-Binding) is applied. > In this case, minimally, you filter for "packets destined for address > foo", and the action would be "translate that to address bar". > Scott - the above description is packet centric. Whereas, NAT paradigm is session based. Just because you have an address binding defined on a NAT middlebox, it does not mean that any packet traversing the box can use the binding. Only sessions initiated in a certain direction, or sessions permitted by the agent to use the address binding are allowed to use the binding. If a packet does not belong to any of NAT managed sessions, either the packet is dropped or a new session-state is created (if the packet meets the criteria required of a first packet) > ..Scott > regards, suresh __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 20 10:43:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12130 for ; Thu, 20 Sep 2001 10:43: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 KAA28818; Thu, 20 Sep 2001 10:41: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 KAA28789 for ; Thu, 20 Sep 2001 10:41:26 -0400 (EDT) Received: from web13804.mail.yahoo.com (web13804.mail.yahoo.com [216.136.175.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12099 for ; Thu, 20 Sep 2001 10:41:22 -0400 (EDT) Message-ID: <20010920144045.48549.qmail@web13804.mail.yahoo.com> Received: from [65.12.33.187] by web13804.mail.yahoo.com via HTTP; Thu, 20 Sep 2001 07:40:45 PDT Date: Thu, 20 Sep 2001 07:40:45 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Terminology discussion - regroup To: Mark Duffy , Scott Brim , midcom@ietf.org In-Reply-To: <3.0.5.32.20010919110201.008f5430@email.quarrytech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --- Mark Duffy wrote: > >> If classification is per-packet based, how do you specify session based > >> classification? Is it fair to assume that >> session based classification> and > >> will be classification criteria? > > > >Suresh has a point. Will it be possible to specify stateful > >rules in the midcom protocol, or can rules only be based on individual > >packet attributes? Will stateful inspection be limited to agents? I > >don't think we brought this out in the requirements. > > We had some discussion earlier on about the fact that midcom facilitates > removing application intelligence from the middleboxes, but at what level > does "application" begin. I believe we concluded that middleboxes are > generally expected to remain aware of transport layer protocols e.g. tcp. > (See > http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg00663.htm > l and other messages in that thread.) > I recall the discussion. But, I dont believe that touches upon specifying session-based rules. > Therefore, I have been believing that the Action Spec will include such > possible actions as > - allow individual packets to pass in a certain direction (stateless) > - allow tcp connection in both directions as long as initial syn flows in > a certain direction (tcp-stateful) The first spec above is inherently packet based. The second spec - A TCP trick of being able to permit/deny a TCP session based on the SYN flag of the first packet alone and permitting all TCP packets otherwise - You were able to synthesize a TCP-session based firewall rule into a per-packet firewall rule. Fine. Both these ilustrations are firewall/packet centric and will not suffice for NAT. > > R44 covers the direction aspect. > > See > http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg00977.htm > l for a proposed requirement about the stateful behavior. > > -Mark regards, suresh ===== __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 20 11:36:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13551 for ; Thu, 20 Sep 2001 11:36: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 LAA00503; Thu, 20 Sep 2001 11:31: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 LAA00470 for ; Thu, 20 Sep 2001 11:31:29 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAB13462 for ; Thu, 20 Sep 2001 11:31:25 -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 f8KFUTA13714 for ; Thu, 20 Sep 2001 08:30:29 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-156.cisco.com [10.82.192.156]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ABW01215; Thu, 20 Sep 2001 08:30:15 -0700 (PDT) Message-Id: <5.1.0.14.0.20010920111824.00a4ea40@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 20 Sep 2001 11:32:07 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Back at it Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Let's get back to work on finishing up the requirements, particularly now that we've got basic agreement on terminology. Today's items: R1a: The MIDCOM protocol must enable a MIDCOM agent requiring the services of a middlebox to establish an authorized association between itself and the middlebox. Proposal: keep R10: A middlebox must be able to notify a midcom agent of the following events: Session creation, session termination, MIDCOM protocol failure, middlebox function failure, or any other significant event. Independently, ICMP error codes can be useful to notify transport layer failures to the agents. Proposal: keep, align terminology, delete last sentence (mechanism is out of scope) R13: Agent hosting entity (whatever that is) must be identified in the midcom protocol. Proposal: delete, unless this is intended to say more than the agent must be identified. Otherwise I think it's self-evident (we've got authentication/authorization requirements - identity is implicit in those). R14: Once a connection is established between a middlebox and a MIDCOM agent, that connection should be usable with multiple instances of the application(s), as appropriate. Proposal: if we're going to keep this we need to 1) align the language, and 2) clarify the text quite a bit. I think that this is intended to say that the midcom protocol should be able to support multiplexing requests from different applications and multiple requests from the same application across a single midcom session, yes? Melinda Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 20 12:20:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14744 for ; Thu, 20 Sep 2001 12:20: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 MAA02056; Thu, 20 Sep 2001 12:18: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 MAA02027 for ; Thu, 20 Sep 2001 12:18: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 ESMTP id MAA14683 for ; Thu, 20 Sep 2001 12:18:29 -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 f8KGHZA17423 for ; Thu, 20 Sep 2001 09:17:35 -0700 (PDT) Received: from SBRIM-W2K (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with SMTP id ABE26509; Thu, 20 Sep 2001 09:17:18 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 20 Sep 2001 12:17:11 -0400 Date: Thu, 20 Sep 2001 12:17:10 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Back at it Message-ID: <20010920121710.J1936@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <5.1.0.14.0.20010920111824.00a4ea40@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20010920111824.00a4ea40@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Thu, Sep 20, 2001 at 11:32:07AM -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Thu, Sep 20, 2001 11:32:07AM -0400, Melinda Shore allegedly wrote: > Let's get back to work on finishing up the requirements, > particularly now that we've got basic agreement on terminology. > Today's items: > > R1a: The MIDCOM protocol must enable a MIDCOM agent requiring > the services of a middlebox to establish an authorized > association between itself and the middlebox. > > Proposal: keep OK > R10: A middlebox must be able to notify a midcom agent of > the following events: Session creation, session termination, > MIDCOM protocol failure, middlebox function failure, or any > other significant event. Independently, ICMP error codes > can be useful to notify transport layer failures to the agents. > > Proposal: keep, align terminology, delete last sentence (mechanism > is out of scope) OK. I think we've agreed on 'session' so isn't the terminology aligned? > R13: Agent hosting entity (whatever that is) must be identified in > the midcom protocol. > > Proposal: delete, unless this is intended to say more than the agent > must be identified. Otherwise I think it's self-evident (we've got > authentication/authorization requirements - identity is implicit in > those). OK > R14: Once a connection is established between a middlebox and a MIDCOM > agent, that connection should be usable with multiple instances of > the application(s), as appropriate. > > Proposal: if we're going to keep this we need to 1) align the language, > and 2) clarify the text quite a bit. I think that this is intended to > say that the midcom protocol should be able to support multiplexing > requests from different applications and multiple requests from the same > application across a single midcom session, yes? However, I don't think it means much. The communication between a middlebox and an agent is independent of what might have triggered it. The middlebox is not going to hear about multiple instances of an application. Specifically, first it means an agent needs to be able to ask for multiple different rulesets. Enh. That's obvious enough that we can skip it. Second, though, IF at some future date rules can include stateful inspection mechanisms, then it also means that a single agent must be able to request more than one of those. Since we're not going there in this incarnation of the working group, I think this requirement should be punted. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 20 13:00:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15860 for ; Thu, 20 Sep 2001 13:00: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 MAA02842; Thu, 20 Sep 2001 12:40: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 MAA02808 for ; Thu, 20 Sep 2001 12:40:09 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15337 for ; Thu, 20 Sep 2001 12:40:07 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12ST5V; Thu, 20 Sep 2001 12:38:58 -0400 Message-Id: <3.0.5.32.20010920123544.00896540@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 20 Sep 2001 12:35:44 -0400 To: Pyda Srisuresh , midcom@ietf.org From: Mark Duffy Subject: Re: [midcom] Terminology discussion - regroup In-Reply-To: <20010920144045.48549.qmail@web13804.mail.yahoo.com> References: <3.0.5.32.20010919110201.008f5430@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org >> Therefore, I have been believing that the Action Spec will include such >> possible actions as >> - allow individual packets to pass in a certain direction (stateless) >> - allow tcp connection in both directions as long as initial syn flows in >> a certain direction (tcp-stateful) > >The first spec above is inherently packet based. >The second spec - A TCP trick of being able to permit/deny a TCP session >based on the SYN flag of the first packet alone and permitting all TCP >packets otherwise - You were able to synthesize a TCP-session based >firewall rule into a per-packet firewall rule. Fine. I wouldn't call that a "trick". Perhaps you are reacting to my wording, which was quite specific in an attempt to convey the point succinctly by example. Let me try wording the stateful type action more generally: - allow packets to pass in both directions within a transport layer (e.g. tcp) connection/sesssion/whatever as long as the connection/sesssion/whatever is initiated in a certain direction. (firewall stateful action spec) >Both these ilustrations are firewall/packet centric and will not >suffice for NAT. I would see NAPT being much the same: apply a translation on a per-transport-layer session basis. Just as with stateful firewall rule, the middlebox must be aware of the transport layer sessions. However, for NAT without port translation, the middlebox doesn't need to be aware of the trasnport sessions. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 20 13:05:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16014 for ; Thu, 20 Sep 2001 13:05: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 NAA03439; Thu, 20 Sep 2001 13:01: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 NAA03390 for ; Thu, 20 Sep 2001 13:00:59 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15857 for ; Thu, 20 Sep 2001 13:00:56 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A0A0219801D8; Thu, 20 Sep 2001 13:00:16 -0400 Message-ID: <000f01c141f3$c7a93ca0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Scott Brim" , References: <5.1.0.14.0.20010920111824.00a4ea40@mira-sjc5-4.cisco.com> <20010920121710.J1936@SBRIM-W2K> Subject: Re: [midcom] Back at it Date: Thu, 20 Sep 2001 12:46:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.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: "Scott Brim" To: Sent: Thursday, September 20, 2001 12:17 PM Subject: Re: [midcom] Back at it > On Thu, Sep 20, 2001 11:32:07AM -0400, Melinda Shore allegedly wrote: > > Let's get back to work on finishing up the requirements, > > particularly now that we've got basic agreement on terminology. > > Today's items: > > > > R1a: The MIDCOM protocol must enable a MIDCOM agent requiring > > the services of a middlebox to establish an authorized > > association between itself and the middlebox. > > > > Proposal: keep > > OK agreed > > > R10: A middlebox must be able to notify a midcom agent of > > the following events: Session creation, session termination, > > MIDCOM protocol failure, middlebox function failure, or any > > other significant event. Independently, ICMP error codes > > can be useful to notify transport layer failures to the agents. > > > > Proposal: keep, align terminology, delete last sentence (mechanism > > is out of scope) > > OK. I think we've agreed on 'session' so isn't the terminology aligned? I interpreted 'session' to be 'ruleset'. For example, if a ruleset has a timer and the timer expired and the ruleset was deleted, the agent would want notification that that occured. Why would one midcom agent care about the establishment or termination of a session with another midcom agent? I thought we agreed that any relationship between midcom agents is out of scope. > > R13: Agent hosting entity (whatever that is) must be identified in > > the midcom protocol. > > > > Proposal: delete, unless this is intended to say more than the agent > > must be identified. Otherwise I think it's self-evident (we've got > > authentication/authorization requirements - identity is implicit in > > those). > > OK agreed > > > R14: Once a connection is established between a middlebox and a MIDCOM > > agent, that connection should be usable with multiple instances of > > the application(s), as appropriate. > > > > Proposal: if we're going to keep this we need to 1) align the language, > > and 2) clarify the text quite a bit. I think that this is intended to > > say that the midcom protocol should be able to support multiplexing > > requests from different applications and multiple requests from the same > > application across a single midcom session, yes? > > However, I don't think it means much. The communication between a > middlebox and an agent is independent of what might have triggered it. > The middlebox is not going to hear about multiple instances of an > application. Specifically, first it means an agent needs to be able to > ask for multiple different rulesets. Enh. That's obvious enough that > we can skip it. Second, though, IF at some future date rules can > include stateful inspection mechanisms, then it also means that a single > agent must be able to request more than one of those. Since we're not > going there in this incarnation of the working group, I think this > requirement should be punted. I can see two intrepretations of this: 1) multiple applications can use the midcom agents one 'session' with the middlebox. How applications interact with a midcom agent or take the role of a midcom agent is beyond the scope of the protocol. 2) the same 'session' between an agent and the middlebox could be used for either the firewall or NAT function or both. I don't think we need to say this. Either way, let's drop it. > > ..Scott > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 20 13:09:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16155 for ; Thu, 20 Sep 2001 13:09: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 NAA03593; Thu, 20 Sep 2001 13:06: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 NAA03568 for ; Thu, 20 Sep 2001 13:06:00 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16033 for ; Thu, 20 Sep 2001 13:05:56 -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 f8KH50A27272 for ; Thu, 20 Sep 2001 10:05:00 -0700 (PDT) Received: from SBRIM-W2K (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with SMTP id ABE27358; Thu, 20 Sep 2001 10:04:46 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 20 Sep 2001 13:04:37 -0400 Date: Thu, 20 Sep 2001 13:04:36 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Terminology discussion - regroup Message-ID: <20010920130436.L1936@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <20010919094335.A1696@SBRIM-W2K> <20010920141719.42122.qmail@web13804.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: <20010920141719.42122.qmail@web13804.mail.yahoo.com>; from srisuresh@yahoo.com on Thu, Sep 20, 2001 at 07:17:19AM -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, Sep 20, 2001 07:17:19AM -0700, Pyda Srisuresh allegedly wrote: > Scott - the above description is packet centric. Whereas, NAT paradigm > is session based. > > Just because you have an address binding defined on a NAT middlebox, > it does not mean that any packet traversing the box can use the binding. > Only sessions initiated in a certain direction, or sessions permitted > by the agent to use the address binding are allowed to use the binding. > If a packet does not belong to any of NAT managed sessions, either the > packet is dropped or a new session-state is created (if the packet meets > the criteria required of a first packet) I think the confusion is over the use of 'session', and it comes down to this paragraph. A "binding" cannot be used unless the use is initiated from a particular direction. What other criteria are which a NAT can use to decide if a particular packet which would use a particular address binding belongs to a "session" which is allowed? _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 20 15:55:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21947 for ; Thu, 20 Sep 2001 15:55: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 PAA12044; Thu, 20 Sep 2001 15:45: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 PAA12013 for ; Thu, 20 Sep 2001 15:45:32 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21685 for ; Thu, 20 Sep 2001 15:45:26 -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 OAA00580 for ; Thu, 20 Sep 2001 14:44:13 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Thu, 20 Sep 2001 14:44:02 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 14:43:53 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F17A@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] Back at it Date: Thu, 20 Sep 2001 14:43:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1420C.93DC65A0" Sender: 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_01C1420C.93DC65A0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Thursday, September 20, 2001 10:32 AM > To: midcom@ietf.org > Subject: [midcom] Back at it > > > Let's get back to work on finishing up the requirements, > particularly now that we've got basic agreement on terminology. > Today's items: > > R1a: The MIDCOM protocol must enable a MIDCOM agent requiring > the services of a middlebox to establish an authorized > association between itself and the middlebox. > > Proposal: keep OK > > R10: A middlebox must be able to notify a midcom agent of > the following events: Session creation, session termination, > MIDCOM protocol failure, middlebox function failure, or any > other significant event. Independently, ICMP error codes > can be useful to notify transport layer failures to the agents. > > Proposal: keep, align terminology, delete last sentence (mechanism > is out of scope) Need to define "Session". Also, I assume that this means asynchronous notification of certain events as they occur at the MB. If "Session" here implies a ruleset, then they'll be created & destroyed at the command of the MA, & they don't need to be notified. The only exception to this is when the timer associated with the ruleset expires (which may terminate the ruleset) - this will need asynchronous notification to the MA. I agree that the last sentence be deleted. > > R13: Agent hosting entity (whatever that is) must be identified in > the midcom protocol. > > Proposal: delete, unless this is intended to say more than the agent > must be identified. Otherwise I think it's self-evident (we've got > authentication/authorization requirements - identity is implicit in > those). Agreed. > > R14: Once a connection is established between a middlebox and a MIDCOM > agent, that connection should be usable with multiple instances of > the application(s), as appropriate. > > Proposal: if we're going to keep this we need to 1) align the > language, > and 2) clarify the text quite a bit. I think that this is intended to > say that the midcom protocol should be able to support multiplexing > requests from different applications and multiple requests > from the same > application across a single midcom session, yes? The session between the MA and the MB should be transparent to the end applications, which is obvious. Not sure whether this requirement tries to convey anything else. If not, delete. Sanjoy ------_=_NextPart_001_01C1420C.93DC65A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Back at it

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Thursday, September 20, 2001 10:32 = AM
> To: midcom@ietf.org
> Subject: [midcom] Back at it
>
>
> Let's get back to work on finishing up the = requirements,
> particularly now that we've got basic agreement = on terminology.
> Today's items:
>
> R1a: The MIDCOM protocol must enable a MIDCOM = agent requiring
>     the services of a = middlebox to establish an authorized
>     association between = itself and the middlebox.
>
> Proposal: keep

OK

>
> R10: A middlebox must be able to notify a = midcom agent of
>     the following events: = Session creation, session termination,
>     MIDCOM protocol = failure, middlebox function failure, or any
>     other significant = event.  Independently, ICMP error codes
>     can be useful to notify = transport layer failures to the agents.
>
> Proposal: keep, align terminology, delete last = sentence (mechanism
> is out of scope)

Need to define "Session". Also, I assume = that this means asynchronous notification of certain events as they = occur at the MB. If "Session" here implies a ruleset, then = they'll be created & destroyed at the command of the MA, & they = don't need to be notified. The only exception to this is when the timer = associated with the ruleset expires (which may terminate the ruleset) - = this will need asynchronous notification to the MA.

I agree that the last sentence be deleted.

>
> R13: Agent hosting entity (whatever that is) = must be identified in
>     the midcom = protocol.
>
> Proposal: delete, unless this is intended to = say more than the agent
> must be identified.  Otherwise I think = it's self-evident (we've got
> authentication/authorization requirements - = identity is implicit in
> those).

Agreed.

>
> R14: Once a connection is established between a = middlebox and a MIDCOM
> agent, that connection should be usable with = multiple instances of
> the application(s), as appropriate.
>
> Proposal: if we're going to keep this we need = to 1) align the
> language,
> and 2) clarify the text quite a bit.  I = think that this is intended to
> say that the midcom protocol should be able to = support multiplexing
> requests from different applications and = multiple requests
> from the same
> application across a single midcom session, = yes?

 The session between the MA and the MB should be = transparent to the end applications, which is obvious. Not sure whether = this requirement tries to convey anything else. If not, = delete.

Sanjoy

------_=_NextPart_001_01C1420C.93DC65A0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 20 17:26: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 ESMTP id RAA23794 for ; Thu, 20 Sep 2001 17:26: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 RAA14391; Thu, 20 Sep 2001 17:14:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14366 for ; Thu, 20 Sep 2001 17:14:35 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23576 for ; Thu, 20 Sep 2001 17:14:31 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12S4WX; Thu, 20 Sep 2001 17:13:24 -0400 Message-Id: <3.0.5.32.20010920171232.0097f500@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 20 Sep 2001 17:12:32 -0400 To: "Bob Penfield" , "Scott Brim" , From: Mark Duffy Subject: Re: [midcom] Back at it In-Reply-To: <000f01c141f3$c7a93ca0$2300000a@acmepacket.com> References: <5.1.0.14.0.20010920111824.00a4ea40@mira-sjc5-4.cisco.com> <20010920121710.J1936@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 12:46 PM 9/20/01 -0400, Bob Penfield wrote: > >----- Original Message ----- >From: "Scott Brim" >To: >Sent: Thursday, September 20, 2001 12:17 PM >Subject: Re: [midcom] Back at it > > >> On Thu, Sep 20, 2001 11:32:07AM -0400, Melinda Shore allegedly wrote: >> > Let's get back to work on finishing up the requirements, >> > particularly now that we've got basic agreement on terminology. >> > Today's items: >> > >> > R1a: The MIDCOM protocol must enable a MIDCOM agent requiring >> > the services of a middlebox to establish an authorized >> > association between itself and the middlebox. >> > >> > Proposal: keep >> >> OK >agreed Keep, but I think s/authorized/authenticated Either that or s/authorized// and cover the security aspect somewhere else (such as second half of R33), but in that case what of value is left of R1a? Presumably the authorization is controlled by policy mechanisms out of scope of midcom and the parties will not bring up the session with unauthorized peers. But the authentication mechanism is a necessary part of the "midcom protocol". Indeed without authentication, the authorization is vacuous. >> > R10: A middlebox must be able to notify a midcom agent of >> > the following events: Session creation, session termination, >> > MIDCOM protocol failure, middlebox function failure, or any >> > other significant event. Independently, ICMP error codes >> > can be useful to notify transport layer failures to the agents. >> > >> > Proposal: keep, align terminology, delete last sentence (mechanism >> > is out of scope) >> >> OK. I think we've agreed on 'session' so isn't the terminology aligned? > >I interpreted 'session' to be 'ruleset'. For example, if a ruleset has a >timer and the timer expired and the ruleset was deleted, the agent would >want notification that that occured. > >Why would one midcom agent care about the establishment or termination of a >session with another midcom agent? I thought we agreed that any relationship >between midcom agents is out of scope. My interpretation of "session" was like Bob's (e.g. VoIP media session). If that's what it really means, I'd propose replacing "Session creation, session termination" with "ruleset expiration". This would cover notifying the agent if the ruleset a) times out, or b) becomes obsolete because the transport session the ruleset was for closed. I would also propose removing "MIDCOM protocol failure". If the midcom protocol has failed, how can we use it to notify the peer of anything? >> > R13: Agent hosting entity (whatever that is) must be identified in >> > the midcom protocol. >> > >> > Proposal: delete, unless this is intended to say more than the agent >> > must be identified. Otherwise I think it's self-evident (we've got >> > authentication/authorization requirements - identity is implicit in >> > those). >> >> OK >agreed ditto >> > R14: Once a connection is established between a middlebox and a MIDCOM >> > agent, that connection should be usable with multiple instances of >> > the application(s), as appropriate. >> > >> > Proposal: if we're going to keep this we need to 1) align the language, >> > and 2) clarify the text quite a bit. I think that this is intended to >> > say that the midcom protocol should be able to support multiplexing >> > requests from different applications and multiple requests from the same >> > application across a single midcom session, yes? >> >> However, I don't think it means much. The communication between a >> middlebox and an agent is independent of what might have triggered it. >> The middlebox is not going to hear about multiple instances of an >> application. Specifically, first it means an agent needs to be able to >> ask for multiple different rulesets. Enh. That's obvious enough that >> we can skip it. Second, though, IF at some future date rules can >> include stateful inspection mechanisms, then it also means that a single >> agent must be able to request more than one of those. Since we're not >> going there in this incarnation of the working group, I think this >> requirement should be punted. > >I can see two intrepretations of this: > >1) multiple applications can use the midcom agents one 'session' with the >middlebox. How applications interact with a midcom agent or take the role of >a midcom agent is beyond the scope of the protocol. > >2) the same 'session' between an agent and the middlebox could be used for >either the firewall or NAT function or both. I don't think we need to say >this. > >Either way, let's drop it. Yes. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 21 10:08:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26014 for ; Fri, 21 Sep 2001 10:08:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14434; Fri, 21 Sep 2001 10:00: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 KAA14397 for ; Fri, 21 Sep 2001 10:00:39 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25712 for ; Fri, 21 Sep 2001 10:01:17 -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 f8LE0MA02707 for ; Fri, 21 Sep 2001 07:00:22 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-87.cisco.com [10.82.192.87]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACA20511; Fri, 21 Sep 2001 07:00:08 -0700 (PDT) Message-Id: <5.1.0.14.0.20010921095614.00a74410@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 21 Sep 2001 10:02:02 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] pre-midcom work item Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org There has been considerable pressure for the IETF to come up with a short-term approach to getting through firewalls and NATs until midcom is available and widely deployed. Because of that we've been asked to add a quick-turnaround deliverable to our charter. The text of the charter addition will very likely be tweaked, but currently looks something like: Ubiquitous deployment of midcom in all middleboxes could take many years. In the interim, a solution is needed that allows applications to operate in the presence of midcom-unaware middleboxes. To support this, the midcom group will develop or document a protocol or approach that allows clients to indirectly obtain address bindings from midcom-unaware middleboxes, through communications with server elements on the public side of the middlebox. The key goals for this effort are rapid delivery of a simple solution (since it is an interim solution), consistency with the midcom framework, and security. The proposed milestone date for this is October 2001 (i.e. next month). This would need to be accepted by the working group. If there are objections or concerns please let us know ASAP. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 21 11:15: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 ESMTP id LAA28094 for ; Fri, 21 Sep 2001 11:15: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 LAA16089; Fri, 21 Sep 2001 11:05: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 LAA16060 for ; Fri, 21 Sep 2001 11:05:33 -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 ESMTP id LAA27833 for ; Fri, 21 Sep 2001 11:05: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 LAA14265; Fri, 21 Sep 2001 11:05:00 -0400 (EDT) Message-Id: <200109211505.LAA14265@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Melinda Shore cc: midcom@ietf.org Subject: Re: [midcom] pre-midcom work item In-reply-to: Your message of "Fri, 21 Sep 2001 10:02:02 EDT." <5.1.0.14.0.20010921095614.00a74410@mira-sjc5-4.cisco.com> Date: Fri, 21 Sep 2001 11:04:59 -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 > There has been considerable pressure for the IETF to come up > with a short-term approach to getting through firewalls and > NATs until midcom is available and widely deployed. I fully support this idea. However, I'd like to propose a slight change to the charter tweak: > Ubiquitous deployment of a new middlebox control protocol would take many > years. A short-term solution is needed to allow applications to operate > in the presence of existing middleboxes. To support this, the midcom > group will develop or document a protocol or approach that allows clients to > indirectly obtain address bindings from midcom-unaware middleboxes, through > communications with server elements on the public side of the middlebox. The > key goals for this effort are rapid delivery of a simple solution (since it > is an interim solution) and security. This means almost the same thing as the existing tweak, but it doesn't presume that midcom will ever be widely deployed. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 21 12:02: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 ESMTP id MAA29482 for ; Fri, 21 Sep 2001 12:02: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 LAA17055; Fri, 21 Sep 2001 11:57: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 LAA17024 for ; Fri, 21 Sep 2001 11:57:26 -0400 (EDT) Received: from web14303.mail.yahoo.com (web14303.mail.yahoo.com [216.136.173.79]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29351 for ; Fri, 21 Sep 2001 11:58:03 -0400 (EDT) Message-ID: <20010921155726.67334.qmail@web14303.mail.yahoo.com> Received: from [134.117.114.52] by web14303.mail.yahoo.com via HTTP; Fri, 21 Sep 2001 11:57:26 EDT Date: Fri, 21 Sep 2001 11:57:26 -0400 (EDT) From: Abdallah Rayhan Subject: Re: [midcom] pre-midcom work item To: Melinda Shore , midcom@ietf.org In-Reply-To: <5.1.0.14.0.20010921095614.00a74410@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 I do object adding this to the charter. This is the nail that would break what the WG is set to deliver in the first place. Interim solutions will be permanent once deployed, to start with. Secondly, this introduces new architectural constraints that is going to screw the consensus achieved so far on the architecture draft. Thirdly, this addition to the charter seems to be an imposed ad-hoc solution rather than a charter requirement. It also suggests that NAT is the only problem which far from the truth. The deployment argument of IKE/IPSec, IP6, MPLS didnt stop the WGs from developing those standards. Why should we be the exception? regards Abdallah Rayhan --- Melinda Shore wrote: > Ubiquitous deployment of midcom in all middleboxes could > take many years. In the interim, a solution is needed that > allows applications to operate in the presence of midcom-unaware > middleboxes. To support this, the midcom group will develop or > document a protocol or approach that allows clients to > indirectly obtain address bindings from midcom-unaware > middleboxes, through communications with server elements on > the public side of the middlebox. The key goals for this > effort are rapid delivery of a simple solution (since it > is an interim solution), consistency with the midcom framework, > and security. > _______________________________________________________ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 21 12:35:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00631 for ; Fri, 21 Sep 2001 12:35: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 MAA18458; Fri, 21 Sep 2001 12:26: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 MAA18418 for ; Fri, 21 Sep 2001 12:26:48 -0400 (EDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00296 for ; Fri, 21 Sep 2001 12:27:23 -0400 (EDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Sep 2001 09:26:11 -0700 Received: from 157.54.7.67 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 21 Sep 2001 09:26:11 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Sep 2001 09:26:10 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Sep 2001 09:26:05 -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, 21 Sep 2001 09:25:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] pre-midcom work item Date: Fri, 21 Sep 2001 09:25:10 -0700 Message-ID: Thread-Topic: [midcom] pre-midcom work item Thread-Index: AcFCuCC6agnPzYLwRxuYh0Mz2tIMXwAAUSZQ From: "Christian Huitema" To: "Abdallah Rayhan" , "Melinda Shore" , X-OriginalArrivalTime: 21 Sep 2001 16:25:10.0746 (UTC) FILETIME=[FC020BA0:01C142B9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA18419 Sender: 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 support inclusion of this item in the charter. It can be done in parallel with the deployment of Midcom. While it is true that NAT are not the only problem we have to solve, NATs, and especially the "$200 box" variations, are a real problem in the deployment of many applications. In fact, proprietary solutions already exist and are already deployed; having a standard would ease deployment of compatible software by multiple vendors. -- Christian Huitema > -----Original Message----- > From: Abdallah Rayhan [mailto:ar_rayhan@yahoo.ca] > Sent: Friday, September 21, 2001 8:57 AM > To: Melinda Shore; midcom@ietf.org > Subject: Re: [midcom] pre-midcom work item > > I do object adding this to the charter. This is the nail > that would break what the WG is set to deliver in the > first place. Interim solutions will be permanent > once deployed, to start with. Secondly, this introduces > new architectural constraints that is going to screw > the consensus achieved so far on the architecture draft. > Thirdly, this addition to the charter seems to be an > imposed ad-hoc solution rather than a charter requirement. > It also suggests that NAT is the only problem which far > from the truth. > > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop > the WGs from developing those standards. Why should we be > the exception? > > regards > Abdallah Rayhan > > --- Melinda Shore wrote: > > Ubiquitous deployment of midcom in all middleboxes could > > take many years. In the interim, a solution is needed that > > allows applications to operate in the presence of midcom-unaware > > middleboxes. To support this, the midcom group will develop or > > document a protocol or approach that allows clients to > > indirectly obtain address bindings from midcom-unaware > > middleboxes, through communications with server elements on > > the public side of the middlebox. The key goals for this > > effort are rapid delivery of a simple solution (since it > > is an interim solution), consistency with the midcom framework, > > and security. > > > > > _______________________________________________________ > Do You Yahoo!? > Get your free @yahoo.ca address at http://mail.yahoo.ca > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 21 12:53: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 ESMTP id MAA01292 for ; Fri, 21 Sep 2001 12:53: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 MAA19126; Fri, 21 Sep 2001 12:45: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 MAA19093 for ; Fri, 21 Sep 2001 12:45:37 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00990 for ; Fri, 21 Sep 2001 12:46:15 -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 LAA16707 for ; Fri, 21 Sep 2001 11:45:06 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Fri, 21 Sep 2001 11:45:00 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Sep 2001 11:44:52 -0500 Message-ID: From: "Mary Barnes" To: Melinda Shore , midcom Cc: "'Christian Huitema'" , Abdallah Rayhan Subject: RE: [midcom] pre-midcom work item Date: Fri, 21 Sep 2001 11:44:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C142BC.BA508AD0" Sender: 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_01C142BC.BA508AD0 Content-Type: text/plain; charset="iso-8859-1" Hi all, For clarification, is this work that you're proposing as a result of the adhoc session on Firewall Traversal in which it was agreed that there is a need for a pre-midcom "Average Current Practice"? Details of that meeting are at: http://www.softarmor.com/sipwg/meets/ietf51/minutes/fwtraversal.html If so, then I would agree to the need for this work to happen. However, it would seem that we would a separate mailing list, etc., so as not to detract from the currently chartered work. Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: Friday, September 21, 2001 11:25 AM To: Abdallah Rayhan; Melinda Shore; midcom Subject: RE: [midcom] pre-midcom work item I support inclusion of this item in the charter. It can be done in parallel with the deployment of Midcom. While it is true that NAT are not the only problem we have to solve, NATs, and especially the "$200 box" variations, are a real problem in the deployment of many applications. In fact, proprietary solutions already exist and are already deployed; having a standard would ease deployment of compatible software by multiple vendors. -- Christian Huitema > -----Original Message----- > From: Abdallah Rayhan [mailto:ar_rayhan@yahoo.ca] > Sent: Friday, September 21, 2001 8:57 AM > To: Melinda Shore; midcom@ietf.org > Subject: Re: [midcom] pre-midcom work item > > I do object adding this to the charter. This is the nail > that would break what the WG is set to deliver in the > first place. Interim solutions will be permanent > once deployed, to start with. Secondly, this introduces > new architectural constraints that is going to screw > the consensus achieved so far on the architecture draft. > Thirdly, this addition to the charter seems to be an > imposed ad-hoc solution rather than a charter requirement. > It also suggests that NAT is the only problem which far > from the truth. > > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop > the WGs from developing those standards. Why should we be > the exception? > > regards > Abdallah Rayhan > > --- Melinda Shore wrote: > > Ubiquitous deployment of midcom in all middleboxes could > > take many years. In the interim, a solution is needed that > > allows applications to operate in the presence of midcom-unaware > > middleboxes. To support this, the midcom group will develop or > > document a protocol or approach that allows clients to > > indirectly obtain address bindings from midcom-unaware > > middleboxes, through communications with server elements on > > the public side of the middlebox. The key goals for this > > effort are rapid delivery of a simple solution (since it > > is an interim solution), consistency with the midcom framework, > > and security. > > > > > _______________________________________________________ > Do You Yahoo!? > Get your free @yahoo.ca address at http://mail.yahoo.ca > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C142BC.BA508AD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] pre-midcom work item

Hi all,

For clarification, is this work that you're proposing = as a result of the adhoc session on Firewall Traversal in which it was = agreed that there is a need for a pre-midcom "Average Current = Practice"?  Details of that meeting are at:

http://www.softarmor.com/sipwg/meets/ietf51/minutes/fw= traversal.html

If so, then I would agree to the need for this work = to happen. However, it would seem that we would a separate mailing = list, etc., so as not to detract from the currently chartered = work.

Regards,
Mary H. Barnes
mbarnes@nortelnetworks.com
972-684-5432
Wireless 817-703-4806


-----Original Message-----
From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
Sent: Friday, September 21, 2001 11:25 AM
To: Abdallah Rayhan; Melinda Shore; midcom
Subject: RE: [midcom] pre-midcom work item


I support inclusion of this item in the charter. It = can be done in
parallel with the deployment of Midcom. While it is = true that NAT are
not the only problem we have to solve, NATs, and = especially the "$200
box" variations, are a real problem in the = deployment of many
applications. In fact, proprietary solutions already = exist and are
already deployed; having a standard would ease = deployment of compatible
software by multiple vendors.

-- Christian Huitema

> -----Original Message-----
> From: Abdallah Rayhan [mailto:ar_rayhan@yahoo.ca]=
> Sent: Friday, September 21, 2001 8:57 AM
> To: Melinda Shore; midcom@ietf.org
> Subject: Re: [midcom] pre-midcom work = item
>
> I do object adding this to the charter. This is = the nail
> that would break what the WG is set to deliver = in the
> first place. Interim solutions will be = permanent
> once deployed, to start with. Secondly, this = introduces
> new architectural constraints that is going to = screw
> the consensus achieved so far on the = architecture draft.
> Thirdly, this addition to the charter seems to = be an
> imposed ad-hoc solution rather than a charter = requirement.
> It also suggests that NAT is the only problem = which far
> from the truth.
>
> The deployment argument of IKE/IPSec, IP6, MPLS = didnt stop
> the WGs from developing those standards. Why = should we be
> the exception?
>
> regards
> Abdallah Rayhan
>
> --- Melinda Shore <mshore@cisco.com> = wrote:
> > Ubiquitous deployment of midcom in all = middleboxes could
> > take many years.  In the interim, a = solution is needed that
> > allows applications to operate in the = presence of midcom-unaware
> > middleboxes. To support this, the midcom = group will develop or
> > document a protocol or approach that = allows clients to
> > indirectly obtain address bindings from = midcom-unaware
> > middleboxes, through communications with = server elements on
> > the public side of the middlebox.  = The key goals for this
> > effort are rapid delivery of a simple = solution (since it
> > is an interim solution), consistency with = the midcom framework,
> > and security.
> >
>
>
> = _______________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.ca address at http://mail.yahoo.ca
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom

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

------_=_NextPart_001_01C142BC.BA508AD0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 21 12:57:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01421 for ; Fri, 21 Sep 2001 12:57: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 MAA19234; Fri, 21 Sep 2001 12:51: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 MAA19205 for ; Fri, 21 Sep 2001 12:51:15 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01222 for ; Fri, 21 Sep 2001 12:51:53 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8LGnh8P023810; Fri, 21 Sep 2001 12:49:43 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Sep 2001 12:50:43 -0400 Message-ID: From: Jonathan Rosenberg To: "'Abdallah Rayhan'" , Melinda Shore , midcom@ietf.org Subject: RE: [midcom] pre-midcom work item Date: Fri, 21 Sep 2001 12:50:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I **>STRONGLY<** support the inclusion of this item into the charter. Just so people are crystal clear on what this is talkign about, it is referring to the kind of protocol described in: http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-02.txt Specifically, the "reflector" protocol described there. I have split this protocol out as a separate, sip independent document, and am working with some colleagues to finish it up. Expect to see a draft shortly. Responses to Abdallah inline: > -----Original Message----- > From: Abdallah Rayhan [mailto:ar_rayhan@yahoo.ca] > Sent: Friday, September 21, 2001 11:57 AM > To: Melinda Shore; midcom@ietf.org > Subject: Re: [midcom] pre-midcom work item > > > I do object adding this to the charter. This is the nail > that would break what the WG is set to deliver in the > first place. Interim solutions will be permanent > once deployed, to start with. That is only true when the motivation to upgrade is not there. However, the solution we are talking about here does not solve the full scope of problems midcom is solving. In particular: * it does not address firewall control * it has no story around fault tolerance * it doesn't address twice nat * it won't work properly in networks with multiple natted egress points As such, the proposed addition is really targeted at the residential and small enterprise markets. I think that it will never be acceptable to carriers or large enterprises, which need a real midcom solution. These particular markets are also problematic because its not just an issue of when midcom is finished. The administrator of the nat, in many cases, is NOT the one who is responsible for delivery of applications. As such, even if a midcom nat is available, these administrators will not be incented to upgrade, since there is no reason. The case I always use is that of an airport Internet lounge, which has a nat. The lounge provides connectivity, and thats it. They don't care, and may not even know, about apps like VoIP. They will not be incented to upgrade those nats to midcom enabled ones. We need solutions for those kinds of scenarios. > Secondly, this introduces > new architectural constraints that is going to screw > the consensus achieved so far on the architecture draft. How is that? > Thirdly, this addition to the charter seems to be an > imposed ad-hoc solution rather than a charter requirement. > It also suggests that NAT is the only problem which far > from the truth. Agreed, which is why midcom remains important. This addition will help us deal with very very real, very very problematic retail deployment scenarios which are currently on hold because of NAT. > > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop > the WGs from developing those standards. Why should we be > the exception? No one is saying that it should not be deployed. Full steam ahead. We need midcom, and that hasn't changed. The fact is that midcom can't fully solve our problems. Its also worth noting that there are already solutions being deployed today that play the role of the proposed addition. Those are all proprietary and not interoperable. Let us not let that continue. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 21 13:00:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01576 for ; Fri, 21 Sep 2001 13:00: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 MAA19364; Fri, 21 Sep 2001 12:53: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 MAA19286 for ; Fri, 21 Sep 2001 12:53:21 -0400 (EDT) Received: from WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com ([131.107.3.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01304 for ; Fri, 21 Sep 2001 12:53:57 -0400 (EDT) Received: from win-hub-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.229]) by WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Sep 2001 09:52:43 -0700 Received: from 157.54.5.226 by win-hub-01.wingroup.windeploy.ntdev.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 21 Sep 2001 09:52:43 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-hub-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Sep 2001 09:52:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: [midcom] pre-midcom work item Date: Fri, 21 Sep 2001 09:52:42 -0700 Message-ID: Thread-Topic: [midcom] pre-midcom work item Thread-Index: AcFCvMl3mSebmLKpRd+QET/W4CQ2XAAAP8yw From: "Christian Huitema" To: "Mary Barnes" , "Melinda Shore" , "midcom" Cc: "Abdallah Rayhan" X-OriginalArrivalTime: 21 Sep 2001 16:52:43.0375 (UTC) FILETIME=[D50D37F0:01C142BD] Sender: 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. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C142BD.D4CF6555" ------_=_NextPart_001_01C142BD.D4CF6555 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The discussions were actually held in the AVT and MMUSIC working groups. =20 -----Original Message----- From: Mary Barnes [mailto:mbarnes@nortelnetworks.com]=20 Sent: Friday, September 21, 2001 9:45 AM To: Melinda Shore; midcom Cc: Christian Huitema; Abdallah Rayhan Subject: RE: [midcom] pre-midcom work item =20 Hi all,=20 For clarification, is this work that you're proposing as a result of the adhoc session on Firewall Traversal in which it was agreed that there is a need for a pre-midcom "Average Current Practice"? Details of that meeting are at: http://www.softarmor.com/sipwg/meets/ietf51/minutes/fwtraversal.html=20 If so, then I would agree to the need for this work to happen. However, it would seem that we would a separate mailing list, etc., so as not to detract from the currently chartered work. Regards,=20 Mary H. Barnes=20 mbarnes@nortelnetworks.com=20 972-684-5432=20 Wireless 817-703-4806=20 =20 -----Original Message-----=20 From: Christian Huitema [mailto:huitema@windows.microsoft.com]=20 Sent: Friday, September 21, 2001 11:25 AM=20 To: Abdallah Rayhan; Melinda Shore; midcom=20 Subject: RE: [midcom] pre-midcom work item=20 =20 I support inclusion of this item in the charter. It can be done in=20 parallel with the deployment of Midcom. While it is true that NAT are=20 not the only problem we have to solve, NATs, and especially the "$200=20 box" variations, are a real problem in the deployment of many=20 applications. In fact, proprietary solutions already exist and are=20 already deployed; having a standard would ease deployment of compatible=20 software by multiple vendors.=20 -- Christian Huitema=20 > -----Original Message-----=20 > From: Abdallah Rayhan [mailto:ar_rayhan@yahoo.ca]=20 > Sent: Friday, September 21, 2001 8:57 AM=20 > To: Melinda Shore; midcom@ietf.org=20 > Subject: Re: [midcom] pre-midcom work item=20 >=20 > I do object adding this to the charter. This is the nail=20 > that would break what the WG is set to deliver in the=20 > first place. Interim solutions will be permanent=20 > once deployed, to start with. Secondly, this introduces=20 > new architectural constraints that is going to screw=20 > the consensus achieved so far on the architecture draft.=20 > Thirdly, this addition to the charter seems to be an=20 > imposed ad-hoc solution rather than a charter requirement.=20 > It also suggests that NAT is the only problem which far=20 > from the truth.=20 >=20 > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop=20 > the WGs from developing those standards. Why should we be=20 > the exception?=20 >=20 > regards=20 > Abdallah Rayhan=20 >=20 > --- Melinda Shore wrote:=20 > > Ubiquitous deployment of midcom in all middleboxes could=20 > > take many years. In the interim, a solution is needed that=20 > > allows applications to operate in the presence of midcom-unaware=20 > > middleboxes. To support this, the midcom group will develop or=20 > > document a protocol or approach that allows clients to=20 > > indirectly obtain address bindings from midcom-unaware=20 > > middleboxes, through communications with server elements on=20 > > the public side of the middlebox. The key goals for this=20 > > effort are rapid delivery of a simple solution (since it=20 > > is an interim solution), consistency with the midcom framework,=20 > > and security.=20 > >=20 >=20 >=20 > _______________________________________________________=20 > Do You Yahoo!?=20 > Get your free @yahoo.ca address at http://mail.yahoo.ca=20 >=20 > _______________________________________________=20 > midcom mailing list=20 > midcom@ietf.org=20 > http://www1.ietf.org/mailman/listinfo/midcom=20 _______________________________________________=20 midcom mailing list=20 midcom@ietf.org=20 http://www1.ietf.org/mailman/listinfo/midcom=20 ------_=_NextPart_001_01C142BD.D4CF6555 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [midcom] pre-midcom work item

The discussions were actually held = in the AVT and MMUSIC working groups.

 

-----Original Message-----
From: Mary Barnes [mailto:mbarnes@nortelnetworks.com]
Sent: Friday, September = 21, 2001 9:45 AM
To: Melinda Shore; = midcom
Cc: Christian Huitema; = Abdallah Rayhan
Subject: RE: [midcom] = pre-midcom work item

 

Hi all,

For clarification, is this work that you're proposing as a result of the = adhoc session on Firewall Traversal in which it was agreed that there is a = need for a pre-midcom "Average Current Practice"?  Details of that = meeting are at:

http://www.softarmor.com/sipwg/meets/ietf51/minutes/fwt= raversal.html

If so, then I would agree to the need for this work to happen. However, it = would seem that we would a separate mailing list, etc., so as not to detract from = the currently chartered work.

Regards,
Mary H. = Barnes
mbarnes@nortelnetworks.com
972-684-5432
Wireless = 817-703-4806

 

-----Original Message-----
From: Christian Huitema = [mailto:huitema@windows.micr= osoft.com]
Sent: Friday, September = 21, 2001 11:25 AM
To: Abdallah Rayhan; = Melinda Shore; midcom
Subject: RE: [midcom] = pre-midcom work item

 

I support inclusion of this item in the charter. It can be done in =
parallel with the = deployment of Midcom. While it is true that NAT are
not the only problem we = have to solve, NATs, and especially the "$200
box" variations, = are a real problem in the deployment of many
applications. In fact, = proprietary solutions already exist and are
already deployed; having = a standard would ease deployment of compatible
software by multiple = vendors.

-- Christian Huitema

> -----Original Message-----
> From: Abdallah = Rayhan [mailto:ar_rayhan@yahoo.ca]<= /font>
> Sent: Friday, = September 21, 2001 8:57 AM
> To: Melinda Shore; midcom@ietf.org
> Subject: Re: = [midcom] pre-midcom work item
>
> I do object adding = this to the charter. This is the nail
> that would break = what the WG is set to deliver in the
> first place. = Interim solutions will be permanent
> once deployed, to = start with. Secondly, this introduces
> new architectural = constraints that is going to screw
> the consensus = achieved so far on the architecture draft.
> Thirdly, this = addition to the charter seems to be an
> imposed ad-hoc = solution rather than a charter requirement.
> It also suggests = that NAT is the only problem which far
> from the = truth.
>
> The deployment = argument of IKE/IPSec, IP6, MPLS didnt stop
> the WGs from = developing those standards. Why should we be
> the = exception?
>
> = regards
> Abdallah = Rayhan
>
> --- Melinda Shore <mshore@cisco.com> wrote:
> > Ubiquitous = deployment of midcom in all middleboxes could
> > take many = years.  In the interim, a solution is needed that
> > allows = applications to operate in the presence of midcom-unaware
> > middleboxes. = To support this, the midcom group will develop or
> > document a = protocol or approach that allows clients to
> > indirectly = obtain address bindings from midcom-unaware
> > middleboxes, = through communications with server elements on
> > the public = side of the middlebox.  The key goals for this
> > effort are = rapid delivery of a simple solution (since it
> > is an interim = solution), consistency with the midcom framework,
> > and = security.
> > =
>
>
> _______________________________________________________ =
> Do You = Yahoo!?
> Get your free = @yahoo.ca address at http://mail.yahoo.ca
>
> _______________________________________________
> midcom mailing = list
> = midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom=

______________________________________________= _
midcom mailing = list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom=

=00 ------_=_NextPart_001_01C142BD.D4CF6555-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 21 13:08: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 ESMTP id NAA01839 for ; Fri, 21 Sep 2001 13:08: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 NAA19778; Fri, 21 Sep 2001 13:01: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 NAA19745 for ; Fri, 21 Sep 2001 13:01:14 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01613 for ; Fri, 21 Sep 2001 13:01:52 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8LGqb8P023838; Fri, 21 Sep 2001 12:52:37 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Sep 2001 12:53:37 -0400 Message-ID: From: Jonathan Rosenberg To: "'Mary Barnes'" , Melinda Shore , midcom Cc: "'Christian Huitema'" , Abdallah Rayhan Subject: RE: [midcom] pre-midcom work item Date: Fri, 21 Sep 2001 12:53:36 -0400 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 Mary, Yes. This is the same problem that was discussed at that adhoc. I will note that there were maybe 30 people at that adhoc, with nearly unanimous agreement to proceed with a solution. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com -----Original Message----- From: Mary Barnes [mailto:mbarnes@nortelnetworks.com] Sent: Friday, September 21, 2001 12:45 PM To: Melinda Shore; midcom Cc: 'Christian Huitema'; Abdallah Rayhan Subject: RE: [midcom] pre-midcom work item Hi all, For clarification, is this work that you're proposing as a result of the adhoc session on Firewall Traversal in which it was agreed that there is a need for a pre-midcom "Average Current Practice"? Details of that meeting are at: http://www.softarmor.com/sipwg/meets/ietf51/minutes/fwtraversal.html If so, then I would agree to the need for this work to happen. However, it would seem that we would a separate mailing list, etc., so as not to detract from the currently chartered work. Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: Friday, September 21, 2001 11:25 AM To: Abdallah Rayhan; Melinda Shore; midcom Subject: RE: [midcom] pre-midcom work item I support inclusion of this item in the charter. It can be done in parallel with the deployment of Midcom. While it is true that NAT are not the only problem we have to solve, NATs, and especially the "$200 box" variations, are a real problem in the deployment of many applications. In fact, proprietary solutions already exist and are already deployed; having a standard would ease deployment of compatible software by multiple vendors. -- Christian Huitema > -----Original Message----- > From: Abdallah Rayhan [mailto:ar_rayhan@yahoo.ca] > Sent: Friday, September 21, 2001 8:57 AM > To: Melinda Shore; midcom@ietf.org > Subject: Re: [midcom] pre-midcom work item > > I do object adding this to the charter. This is the nail > that would break what the WG is set to deliver in the > first place. Interim solutions will be permanent > once deployed, to start with. Secondly, this introduces > new architectural constraints that is going to screw > the consensus achieved so far on the architecture draft. > Thirdly, this addition to the charter seems to be an > imposed ad-hoc solution rather than a charter requirement. > It also suggests that NAT is the only problem which far > from the truth. > > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop > the WGs from developing those standards. Why should we be > the exception? > > regards > Abdallah Rayhan > > --- Melinda Shore wrote: > > Ubiquitous deployment of midcom in all middleboxes could > > take many years. In the interim, a solution is needed that > > allows applications to operate in the presence of midcom-unaware > > middleboxes. To support this, the midcom group will develop or > > document a protocol or approach that allows clients to > > indirectly obtain address bindings from midcom-unaware > > middleboxes, through communications with server elements on > > the public side of the middlebox. The key goals for this > > effort are rapid delivery of a simple solution (since it > > is an interim solution), consistency with the midcom framework, > > and security. > > > > > _______________________________________________________ > Do You Yahoo!? > Get your free @yahoo.ca address at http://mail.yahoo.ca > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 21 13:12:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01972 for ; Fri, 21 Sep 2001 13:12: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 NAA19858; Fri, 21 Sep 2001 13:06: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 NAA19831 for ; Fri, 21 Sep 2001 13:06:33 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01770 for ; Fri, 21 Sep 2001 13:07:11 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8LGxS8P023889; Fri, 21 Sep 2001 12:59:28 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Sep 2001 13:00:27 -0400 Message-ID: From: Jonathan Rosenberg To: "'Christian Huitema'" , Mary Barnes , Melinda Shore , midcom Cc: Abdallah Rayhan Subject: RE: [midcom] pre-midcom work item Date: Fri, 21 Sep 2001 13:00:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org There are many aspects to the total solution for voip. We need SDP extensions to support non-adjacent RTP/RTCP ports. That has been agreed to in mmusic. We need RTP to allow for non-adjacent RTP/RTCP ports. That has been agreed to in AVT. We need SIP itself to work properly through nats, even without a pre-midcom protocol (not the media, just SIP). That has also been agreed to as a sip working item. To support low latency RTP even in the face of symmetric NATs, we need "symmetric RTP". Thats nothing more than usage of non-adjacent RTP/RTCP ports when you get down to it, plus some SDP signaling enhancements. We already have those in mmusic through the comedia draft. We need a protocol to allow a client in a natted residence or enterprise to learn about the presence of nats between it and the public internet, and to obtain the bindings created by the nat in order to place them into SDP. That is the piece that was discussed during the adhoc, and that is the proposed charter item. We need a document that ties the whole thing together, showing how one could use sip, SDP extensions, and the new reflector protocol to build a variety of different voip configurations that work with nat. That is the purpose of the agreed upon sipping charter item (number 5 on http://www.softarmor.com/sipping/sipping-charter-draft.htm). -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: Friday, September 21, 2001 12:53 PM To: Mary Barnes; Melinda Shore; midcom Cc: Abdallah Rayhan Subject: RE: [midcom] pre-midcom work item The discussions were actually held in the AVT and MMUSIC working groups. -----Original Message----- From: Mary Barnes [mailto:mbarnes@nortelnetworks.com] Sent: Friday, September 21, 2001 9:45 AM To: Melinda Shore; midcom Cc: Christian Huitema; Abdallah Rayhan Subject: RE: [midcom] pre-midcom work item Hi all, For clarification, is this work that you're proposing as a result of the adhoc session on Firewall Traversal in which it was agreed that there is a need for a pre-midcom "Average Current Practice"? Details of that meeting are at: http://www.softarmor.com/sipwg/meets/ietf51/minutes/fwtraversal.html If so, then I would agree to the need for this work to happen. However, it would seem that we would a separate mailing list, etc., so as not to detract from the currently chartered work. Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: Friday, September 21, 2001 11:25 AM To: Abdallah Rayhan; Melinda Shore; midcom Subject: RE: [midcom] pre-midcom work item I support inclusion of this item in the charter. It can be done in parallel with the deployment of Midcom. While it is true that NAT are not the only problem we have to solve, NATs, and especially the "$200 box" variations, are a real problem in the deployment of many applications. In fact, proprietary solutions already exist and are already deployed; having a standard would ease deployment of compatible software by multiple vendors. -- Christian Huitema > -----Original Message----- > From: Abdallah Rayhan [mailto:ar_rayhan@yahoo.ca] > Sent: Friday, September 21, 2001 8:57 AM > To: Melinda Shore; midcom@ietf.org > Subject: Re: [midcom] pre-midcom work item > > I do object adding this to the charter. This is the nail > that would break what the WG is set to deliver in the > first place. Interim solutions will be permanent > once deployed, to start with. Secondly, this introduces > new architectural constraints that is going to screw > the consensus achieved so far on the architecture draft. > Thirdly, this addition to the charter seems to be an > imposed ad-hoc solution rather than a charter requirement. > It also suggests that NAT is the only problem which far > from the truth. > > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop > the WGs from developing those standards. Why should we be > the exception? > > regards > Abdallah Rayhan > > --- Melinda Shore wrote: > > Ubiquitous deployment of midcom in all middleboxes could > > take many years. In the interim, a solution is needed that > > allows applications to operate in the presence of midcom-unaware > > middleboxes. To support this, the midcom group will develop or > > document a protocol or approach that allows clients to > > indirectly obtain address bindings from midcom-unaware > > middleboxes, through communications with server elements on > > the public side of the middlebox. The key goals for this > > effort are rapid delivery of a simple solution (since it > > is an interim solution), consistency with the midcom framework, > > and security. > > > > > _______________________________________________________ > Do You Yahoo!? > Get your free @yahoo.ca address at http://mail.yahoo.ca > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 21 13:30:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAB02392 for ; Fri, 21 Sep 2001 13:30: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 NAA20129; Fri, 21 Sep 2001 13:23: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 NAA20098 for ; Fri, 21 Sep 2001 13:23:20 -0400 (EDT) Received: from exchange_03.2wire.com (gateway.2wire.com [63.203.253.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02209 for ; Fri, 21 Sep 2001 13:23:59 -0400 (EDT) Received: by exchange_03.2wire.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Sep 2001 10:28:38 -0700 Message-ID: <629F94188789D5119577009027E79125215143@exchange_03.2wire.com> From: Randy Turner To: "'Jonathan Rosenberg '" , "''Abdallah Rayhan' '" , "'Melinda Shore '" , "'midcom@ietf.org '" Subject: RE: [midcom] pre-midcom work item Date: Fri, 21 Sep 2001 10:28:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi Jonathan, In one your responses below, you are suggesting that MIDCOM would not solve the problem that this interim work would solve. So these two solutions are orthogonal? That would imply that MIDCOM would not supersede this work at some point, rather *both* would be needed. I'm specifically talking about the point in the thread below: > > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop > the WGs from developing those standards. Why should we be > the exception? Just looking for clarification, Thanks! Randy -----Original Message----- From: Jonathan Rosenberg To: 'Abdallah Rayhan'; Melinda Shore; midcom@ietf.org Sent: 9/21/01 9:50 AM Subject: RE: [midcom] pre-midcom work item I **>STRONGLY<** support the inclusion of this item into the charter. Just so people are crystal clear on what this is talkign about, it is referring to the kind of protocol described in: http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-02.txt Specifically, the "reflector" protocol described there. I have split this protocol out as a separate, sip independent document, and am working with some colleagues to finish it up. Expect to see a draft shortly. Responses to Abdallah inline: > -----Original Message----- > From: Abdallah Rayhan [mailto:ar_rayhan@yahoo.ca] > Sent: Friday, September 21, 2001 11:57 AM > To: Melinda Shore; midcom@ietf.org > Subject: Re: [midcom] pre-midcom work item > > > I do object adding this to the charter. This is the nail > that would break what the WG is set to deliver in the > first place. Interim solutions will be permanent > once deployed, to start with. That is only true when the motivation to upgrade is not there. However, the solution we are talking about here does not solve the full scope of problems midcom is solving. In particular: * it does not address firewall control * it has no story around fault tolerance * it doesn't address twice nat * it won't work properly in networks with multiple natted egress points As such, the proposed addition is really targeted at the residential and small enterprise markets. I think that it will never be acceptable to carriers or large enterprises, which need a real midcom solution. These particular markets are also problematic because its not just an issue of when midcom is finished. The administrator of the nat, in many cases, is NOT the one who is responsible for delivery of applications. As such, even if a midcom nat is available, these administrators will not be incented to upgrade, since there is no reason. The case I always use is that of an airport Internet lounge, which has a nat. The lounge provides connectivity, and thats it. They don't care, and may not even know, about apps like VoIP. They will not be incented to upgrade those nats to midcom enabled ones. We need solutions for those kinds of scenarios. > Secondly, this introduces > new architectural constraints that is going to screw > the consensus achieved so far on the architecture draft. How is that? > Thirdly, this addition to the charter seems to be an > imposed ad-hoc solution rather than a charter requirement. > It also suggests that NAT is the only problem which far > from the truth. Agreed, which is why midcom remains important. This addition will help us deal with very very real, very very problematic retail deployment scenarios which are currently on hold because of NAT. > > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop > the WGs from developing those standards. Why should we be > the exception? No one is saying that it should not be deployed. Full steam ahead. We need midcom, and that hasn't changed. The fact is that midcom can't fully solve our problems. Its also worth noting that there are already solutions being deployed today that play the role of the proposed addition. Those are all proprietary and not interoperable. Let us not let that continue. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 21 13:30: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 ESMTP id NAA02415 for ; Fri, 21 Sep 2001 13:30: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 NAA20079; Fri, 21 Sep 2001 13: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 NAA20051 for ; Fri, 21 Sep 2001 13:22:45 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02199 for ; Fri, 21 Sep 2001 13:23:23 -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 f8LHMQA25078; Fri, 21 Sep 2001 10:22:26 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-87.cisco.com [10.82.192.87]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACB05294; Fri, 21 Sep 2001 10:22:10 -0700 (PDT) Message-Id: <5.1.0.14.0.20010921132214.00a82660@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 21 Sep 2001 13:24:03 -0400 To: "Mary Barnes" , midcom From: Melinda Shore Subject: RE: [midcom] pre-midcom work item 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:44 AM 9/21/01 -0500, Mary Barnes wrote: >For clarification, is this work that you're proposing as a result of the adhoc session on Firewall Traversal in which it was agreed that there is a need for a pre-midcom "Average Current Practice"? Not directly. There's been a lot of pressure for something interim and ugly across several working groups, and the work to do this will be spread across several working groups. The NAT portion has been sent to us in order to ensure consistency with the midcom framework. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 21 14:15:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03665 for ; Fri, 21 Sep 2001 14:15: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 OAA21367; Fri, 21 Sep 2001 14:07: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 OAA21297 for ; Fri, 21 Sep 2001 14:07:05 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03504 for ; Fri, 21 Sep 2001 14:07:42 -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 NAA13936 for ; Fri, 21 Sep 2001 13:06:32 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Fri, 21 Sep 2001 13:06:17 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Sep 2001 13:06:08 -0500 Message-ID: From: "Mary Barnes" To: "'Jonathan Rosenberg'" , Melinda Shore , midcom Cc: "'Christian Huitema'" , Abdallah Rayhan Subject: RE: [midcom] pre-midcom work item Date: Fri, 21 Sep 2001 13:06:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C142C8.123992E0" Sender: 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_01C142C8.123992E0 Content-Type: text/plain; charset="iso-8859-1" Jonathan and Christian, Thanks for the clarifications on the relation of this work to other WGs. I fully support the need to develop an "Average Current Practice" solution for this ASAP (and would agree to doing this in the mainstream MIDCOM WG). I just want to ensure that my comment to take this to a separate list was not mis-interpreted to reflect lack of support. My proposal to take this to a separate mailing list was really an attempt to solve the concerns that were raised that this would be deemed disruptive to the current WG activites. Mary. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, September 21, 2001 11:54 AM To: Barnes, Mary [RICH1:B602:EXCH]; Melinda Shore; midcom Cc: 'Christian Huitema'; Abdallah Rayhan Subject: RE: [midcom] pre-midcom work item Mary, Yes. This is the same problem that was discussed at that adhoc. I will note that there were maybe 30 people at that adhoc, with nearly unanimous agreement to proceed with a solution. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com -----Original Message----- From: Mary Barnes [mailto:mbarnes@nortelnetworks.com] Sent: Friday, September 21, 2001 12:45 PM To: Melinda Shore; midcom Cc: 'Christian Huitema'; Abdallah Rayhan Subject: RE: [midcom] pre-midcom work item Hi all, For clarification, is this work that you're proposing as a result of the adhoc session on Firewall Traversal in which it was agreed that there is a need for a pre-midcom "Average Current Practice"? Details of that meeting are at: http://www.softarmor.com/sipwg/meets/ietf51/minutes/fwtraversal.html If so, then I would agree to the need for this work to happen. However, it would seem that we would a separate mailing list, etc., so as not to detract from the currently chartered work. Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: Friday, September 21, 2001 11:25 AM To: Abdallah Rayhan; Melinda Shore; midcom Subject: RE: [midcom] pre-midcom work item I support inclusion of this item in the charter. It can be done in parallel with the deployment of Midcom. While it is true that NAT are not the only problem we have to solve, NATs, and especially the "$200 box" variations, are a real problem in the deployment of many applications. In fact, proprietary solutions already exist and are already deployed; having a standard would ease deployment of compatible software by multiple vendors. -- Christian Huitema > -----Original Message----- > From: Abdallah Rayhan [mailto:ar_rayhan@yahoo.ca] > Sent: Friday, September 21, 2001 8:57 AM > To: Melinda Shore; midcom@ietf.org > Subject: Re: [midcom] pre-midcom work item > > I do object adding this to the charter. This is the nail > that would break what the WG is set to deliver in the > first place. Interim solutions will be permanent > once deployed, to start with. Secondly, this introduces > new architectural constraints that is going to screw > the consensus achieved so far on the architecture draft. > Thirdly, this addition to the charter seems to be an > imposed ad-hoc solution rather than a charter requirement. > It also suggests that NAT is the only problem which far > from the truth. > > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop > the WGs from developing those standards. Why should we be > the exception? > > regards > Abdallah Rayhan > > --- Melinda Shore wrote: > > Ubiquitous deployment of midcom in all middleboxes could > > take many years. In the interim, a solution is needed that > > allows applications to operate in the presence of midcom-unaware > > middleboxes. To support this, the midcom group will develop or > > document a protocol or approach that allows clients to > > indirectly obtain address bindings from midcom-unaware > > middleboxes, through communications with server elements on > > the public side of the middlebox. The key goals for this > > effort are rapid delivery of a simple solution (since it > > is an interim solution), consistency with the midcom framework, > > and security. > > > > > _______________________________________________________ > Do You Yahoo!? > Get your free @yahoo.ca address at http://mail.yahoo.ca > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C142C8.123992E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] pre-midcom work item

Jonathan and Christian,

Thanks for the clarifications on the relation of this = work to other WGs.  I fully support the need to develop an = "Average Current Practice" solution for this ASAP (and would = agree to doing this in the mainstream MIDCOM WG). 

I just want to ensure that my comment to take this to = a separate list was not mis-interpreted to reflect lack of support. My = proposal to take this to a separate mailing list was really an attempt = to solve the concerns that were raised that this would be deemed = disruptive to the current WG activites. 

Mary.

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Friday, September 21, 2001 11:54 AM
To: Barnes, Mary [RICH1:B602:EXCH]; Melinda Shore; = midcom
Cc: 'Christian Huitema'; Abdallah Rayhan
Subject: RE: [midcom] pre-midcom work item


Mary,

Yes. This is the same problem that was discussed at = that adhoc.

I will note that there were maybe 30 people at that = adhoc, with nearly
unanimous agreement to proceed with a = solution.

-Jonathan R.

---
Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    72 Eagle Rock Ave.
Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
dynamicsoft        &nbs= p;           &nbs= p;            = East Hanover, NJ 07936
jdrosen@dynamicsoft.com      &nbs= p;           &nbs= p;  FAX:   (973) 952-5050
http://www.jdrosen.net    &nbs= p;           &nbs= p;     PHONE: (973) 952-5000
http://www.dynamicsoft.com
 
-----Original Message-----
From: Mary Barnes [mailto:mbarnes@nortelnetworks= .com]
Sent: Friday, September 21, 2001 12:45 PM
To: Melinda Shore; midcom
Cc: 'Christian Huitema'; Abdallah Rayhan
Subject: RE: [midcom] pre-midcom work item


Hi all,
For clarification, is this work that you're = proposing as a result of the
adhoc session on Firewall Traversal in which it was = agreed that there is a
need for a pre-midcom "Average Current = Practice"?  Details of that meeting
are at:
http://www.softarmor.com/sipwg/meets/ietf51/minutes/fw= traversal.html
If so, then I would agree to the need for this work = to happen. However, it
would seem that we would a separate mailing list, = etc., so as not to detract
from the currently chartered work.
Regards,
Mary H. Barnes
mbarnes@nortelnetworks.com
972-684-5432
Wireless 817-703-4806


-----Original Message-----
From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
Sent: Friday, September 21, 2001 11:25 AM
To: Abdallah Rayhan; Melinda Shore; midcom
Subject: RE: [midcom] pre-midcom work item


I support inclusion of this item in the charter. It = can be done in
parallel with the deployment of Midcom. While it is = true that NAT are
not the only problem we have to solve, NATs, and = especially the "$200
box" variations, are a real problem in the = deployment of many
applications. In fact, proprietary solutions already = exist and are
already deployed; having a standard would ease = deployment of compatible
software by multiple vendors.
-- Christian Huitema
> -----Original Message-----
> From: Abdallah Rayhan [mailto:ar_rayhan@yahoo.ca] =
> Sent: Friday, September 21, 2001 8:57 AM =
> To: Melinda Shore; midcom@ietf.org
> Subject: Re: [midcom] pre-midcom work item =
>
> I do object adding this to the charter. This is = the nail
> that would break what the WG is set to deliver = in the
> first place. Interim solutions will be = permanent
> once deployed, to start with. Secondly, this = introduces
> new architectural constraints that is going to = screw
> the consensus achieved so far on the = architecture draft.
> Thirdly, this addition to the charter seems to = be an
> imposed ad-hoc solution rather than a charter = requirement.
> It also suggests that NAT is the only problem = which far
> from the truth.
>
> The deployment argument of IKE/IPSec, IP6, MPLS = didnt stop
> the WGs from developing those standards. Why = should we be
> the exception?
>
> regards
> Abdallah Rayhan
>
> --- Melinda Shore <mshore@cisco.com> = wrote:
> > Ubiquitous deployment of midcom in all = middleboxes could
> > take many years.  In the interim, a = solution is needed that
> > allows applications to operate in the = presence of midcom-unaware
> > middleboxes. To support this, the midcom = group will develop or
> > document a protocol or approach that = allows clients to
> > indirectly obtain address bindings from = midcom-unaware
> > middleboxes, through communications with = server elements on
> > the public side of the middlebox.  = The key goals for this
> > effort are rapid delivery of a simple = solution (since it
> > is an interim solution), consistency with = the midcom framework,
> > and security.
> >
>
>
> = _______________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.ca address at http://mail.yahoo.ca
>
> _______________________________________________ =
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom =
_______________________________________________ =
midcom mailing list
midcom@ietf.org
http://www1.ietf.org/mailman/listinfo/midcom =

------_=_NextPart_001_01C142C8.123992E0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 21 14:57: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 ESMTP id OAA04642 for ; Fri, 21 Sep 2001 14:57:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22127; Fri, 21 Sep 2001 14:49: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 OAA22094 for ; Fri, 21 Sep 2001 14:49:25 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04518 for ; Fri, 21 Sep 2001 14:50:02 -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 f8LImru12048 for ; Fri, 21 Sep 2001 11:48:53 -0700 (PDT) Received: from SBRIM-W2K (ssh-sj1.cisco.com [171.68.225.134]) by airborne.cisco.com (Mirapoint) with SMTP id ABG02576; Fri, 21 Sep 2001 11:48:51 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Fri, 21 Sep 2001 14:48:49 -0400 Date: Fri, 21 Sep 2001 14:48:49 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] pre-midcom work item Message-ID: <20010921144849.D1472@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <5.1.0.14.0.20010921095614.00a74410@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20010921095614.00a74410@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Fri, Sep 21, 2001 at 10:02:02AM -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 you want to document "average current practice" that doesn't need a working group, and I'd suggest that we stay out of it. Let those who are practicing document it. If you want something new, that's an agreed-on standard, it will take more than 4 weeks. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 21 15:03:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04737 for ; Fri, 21 Sep 2001 15:03: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 OAA21971; Fri, 21 Sep 2001 14:36: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 OAA21942 for ; Fri, 21 Sep 2001 14:36:57 -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 OAA04275 for ; Fri, 21 Sep 2001 14:37:34 -0400 (EDT) Message-ID: <20010921183654.1712.qmail@web13803.mail.yahoo.com> Received: from [66.89.112.150] by web13803.mail.yahoo.com via HTTP; Fri, 21 Sep 2001 11:36:54 PDT Date: Fri, 21 Sep 2001 11:36:54 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Terminology discussion - regroup To: Scott Brim , midcom@ietf.org In-Reply-To: <20010920130436.L1936@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: > On Thu, Sep 20, 2001 07:17:19AM -0700, Pyda Srisuresh allegedly wrote: > > Scott - the above description is packet centric. Whereas, NAT paradigm > > is session based. > > > > Just because you have an address binding defined on a NAT middlebox, > > it does not mean that any packet traversing the box can use the binding. > > Only sessions initiated in a certain direction, or sessions permitted > > by the agent to use the address binding are allowed to use the binding. > > If a packet does not belong to any of NAT managed sessions, either the > > packet is dropped or a new session-state is created (if the packet meets > > the criteria required of a first packet) > > I think the confusion is over the use of 'session', and it comes down to > this paragraph. Yes. > A "binding" cannot be used unless the use is initiated > from a particular direction. Right. A binding cannot be used unless a session (in a particular direction w.r.t. to NAT enabled interface) is created to use the binding. > What other criteria are which a NAT can > use to decide if a particular packet which would use a particular > address binding belongs to a "session" which is allowed? > Well, depending upon the NAT type (Basic-NAT, NAPT, bi-directional NAT or Twice-NAT), the NAT device inherently has guidelines to create/permit sessions in a specific direction. Basic-NAT and NAPT, which are the most popular type of NAT types permit outbound sessions only. Hope this helps. Thanks. Regards, suresh __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 21 17:11:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06709 for ; Fri, 21 Sep 2001 17:11: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 RAA24894; Fri, 21 Sep 2001 17:04: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 RAA24863 for ; Fri, 21 Sep 2001 17:04:12 -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 RAA06625 for ; Fri, 21 Sep 2001 17:04:49 -0400 (EDT) Message-ID: <20010921210412.3998.qmail@web13808.mail.yahoo.com> Received: from [66.89.112.150] by web13808.mail.yahoo.com via HTTP; Fri, 21 Sep 2001 14:04:12 PDT Date: Fri, 21 Sep 2001 14:04:12 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] pre-midcom work item To: Melinda Shore , midcom@ietf.org In-Reply-To: <5.1.0.14.0.20010921095614.00a74410@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 --- Melinda Shore wrote: > There has been considerable pressure for the IETF to come up > with a short-term approach to getting through firewalls and > NATs until midcom is available and widely deployed. Because of > that we've been asked to add a quick-turnaround deliverable to > our charter. The text of the charter addition will very likely > be tweaked, but currently looks something like: > > Ubiquitous deployment of midcom in all middleboxes could take many years. In > the interim, a solution is needed that allows applications to operate in the > presence of midcom-unaware middleboxes. To support this, the midcom group > will develop or document a protocol or approach that allows clients to > indirectly obtain address bindings from midcom-unaware middleboxes, through > communications with server elements on the public side of the middlebox. Sounds like, there is a specific proposal behind this. Is this expected to happen with no change to middlebox and a specific set of applications? If so, what specific applications are you contemplating? Why do you believe, the newer protocol protocol (as different from MIDCOM protocol) is sooner to accomplish than MIDCOM? How do you suppose the Interim protocol will inteface with the middleboxes to obatin current address bindings, impose newer address bindings, and do all the resource controlling (and payload manipulation) for the middlebox? Are you thinking SNMP MIBs? Would appreciate if you could throw more light on the thinking behind. Thanks. regards, suresh > The > key goals for this effort are rapid delivery of a simple solution (since it > is an interim solution), consistency with the midcom framework, and > security. > > The proposed milestone date for this is October 2001 (i.e. next month). > > This would need to be accepted by the working group. If there are > objections or concerns please let us know ASAP. > > Thanks, > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 21 17:54:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07272 for ; Fri, 21 Sep 2001 17:54: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 RAA25451; Fri, 21 Sep 2001 17:44: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 RAA25418 for ; Fri, 21 Sep 2001 17:44:50 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07188 for ; Fri, 21 Sep 2001 17:45:27 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A4CF822400B8; Fri, 21 Sep 2001 17:44:47 -0400 Message-ID: <004701c142e6$65433860$2300000a@acmepacket.com> From: "Bob Penfield" To: "Pyda Srisuresh" , "Melinda Shore" , References: <20010921210412.3998.qmail@web13808.mail.yahoo.com> Subject: Re: [midcom] pre-midcom work item Date: Fri, 21 Sep 2001 17:43:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I support the idea of doing this with the midcom WG. I don't think that there is any other WG with participants from as wide a range of applications interested NAT/firewall solutions. The only existing work that I am aware of that matches the "approach that allows clients to indirectly obtain address bindings from midcom-unaware middleboxes" statement is: http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-02.txt Although this contains some SIP-specific sections, those dealing with an endpoint learning its public address are applicable to the general NAT problem. Although 4 weeks is an aggressive target, surely a proposal based on the above document could be completed by the end of the year which is certainly far in advance of any proposed midcom protocol. I also agree with Dr. Rosenberg that this work item covers situations where the ultimate midcom approach would not be appropriate. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Pyda Srisuresh" To: "Melinda Shore" ; Sent: Friday, September 21, 2001 5:04 PM Subject: Re: [midcom] pre-midcom work item > > --- Melinda Shore wrote: > > There has been considerable pressure for the IETF to come up > > with a short-term approach to getting through firewalls and > > NATs until midcom is available and widely deployed. Because of > > that we've been asked to add a quick-turnaround deliverable to > > our charter. The text of the charter addition will very likely > > be tweaked, but currently looks something like: > > > > Ubiquitous deployment of midcom in all middleboxes could take many years. In > > the interim, a solution is needed that allows applications to operate in the > > presence of midcom-unaware middleboxes. To support this, the midcom group > > will develop or document a protocol or approach that allows clients to > > indirectly obtain address bindings from midcom-unaware middleboxes, through > > communications with server elements on the public side of the middlebox. > > Sounds like, there is a specific proposal behind this. Is this expected > to happen with no change to middlebox and a specific set of applications? > If so, what specific applications are you contemplating? > Why do you believe, the newer protocol protocol (as different from > MIDCOM protocol) is sooner to accomplish than MIDCOM? > > How do you suppose the Interim protocol will inteface with the middleboxes > to obatin current address bindings, impose newer address bindings, and do all > the resource controlling (and payload manipulation) for the middlebox? > Are you thinking SNMP MIBs? > > Would appreciate if you could throw more light on the thinking behind. > Thanks. > > regards, > suresh > > The > > key goals for this effort are rapid delivery of a simple solution (since it > > is an interim solution), consistency with the midcom framework, and > > security. > > > > The proposed milestone date for this is October 2001 (i.e. next month). > > > > This would need to be accepted by the working group. If there are > > objections or concerns please let us know ASAP. > > > > Thanks, > > > > Melinda > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www1.ietf.org/mailman/listinfo/midcom > > > __________________________________________________ > Do You Yahoo!? > Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 21 20:41:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08975 for ; Fri, 21 Sep 2001 20: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 UAA28542; Fri, 21 Sep 2001 20:25: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 UAA28514 for ; Fri, 21 Sep 2001 20:25:43 -0400 (EDT) Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08733 for ; Fri, 21 Sep 2001 20:26:21 -0400 (EDT) Received: from 157.54.9.104 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 21 Sep 2001 17:24:45 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Sep 2001 17:24:45 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Sep 2001 17:24:44 -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, 21 Sep 2001 17:24:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] pre-midcom work item Date: Fri, 21 Sep 2001 17:24:40 -0700 Message-ID: Thread-Topic: [midcom] pre-midcom work item Thread-Index: AcFC5GBJQiUMwxKxQliT1qRm9/ypkwAGC42g From: "Christian Huitema" To: "Pyda Srisuresh" , "Melinda Shore" , X-OriginalArrivalTime: 22 Sep 2001 00:24:41.0107 (UTC) FILETIME=[F87ABE30:01C142FC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA28515 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit The design goal is that any interim solution will be fully transparent to the existing NAT, i.e. will not require any participation of the NAT, or any change to the NAT. That, alone, makes it much more likely to be deployed in a very short time frame. -- Christian Huitema > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > Sent: Friday, September 21, 2001 2:04 PM > To: Melinda Shore; midcom@ietf.org > Subject: Re: [midcom] pre-midcom work item > > > --- Melinda Shore wrote: > > There has been considerable pressure for the IETF to come up > > with a short-term approach to getting through firewalls and > > NATs until midcom is available and widely deployed. Because of > > that we've been asked to add a quick-turnaround deliverable to > > our charter. The text of the charter addition will very likely > > be tweaked, but currently looks something like: > > > > Ubiquitous deployment of midcom in all middleboxes could take many > years. In > > the interim, a solution is needed that allows applications to > operate in the > > presence of midcom-unaware middleboxes. To support this, the midcom > group > > will develop or document a protocol or approach that allows clients > to > > indirectly obtain address bindings from midcom-unaware middleboxes, > through > > communications with server elements on the public side of the > middlebox. > > Sounds like, there is a specific proposal behind this. Is this > expected > to happen with no change to middlebox and a specific set of > applications? > If so, what specific applications are you contemplating? > Why do you believe, the newer protocol protocol (as different from > MIDCOM protocol) is sooner to accomplish than MIDCOM? > > How do you suppose the Interim protocol will inteface with the > middleboxes > to obatin current address bindings, impose newer address bindings, and > do all > the resource controlling (and payload manipulation) for the middlebox? > Are you thinking SNMP MIBs? > > Would appreciate if you could throw more light on the thinking behind. > Thanks. > > regards, > suresh > > > The > > key goals for this effort are rapid delivery of a simple solution > (since it > > is an interim solution), consistency with the midcom framework, and > > security. > > > > The proposed milestone date for this is October 2001 (i.e. next > month). > > > > This would need to be accepted by the working group. If there are > > objections or concerns please let us know ASAP. > > > > Thanks, > > > > Melinda > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www1.ietf.org/mailman/listinfo/midcom > > > __________________________________________________ > Do You Yahoo!? > Get email alerts & NEW webcam video instant messaging with Yahoo! > Messenger. http://im.yahoo.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 21 21:27: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 ESMTP id VAA09482 for ; Fri, 21 Sep 2001 21:27: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 VAA29982; Fri, 21 Sep 2001 21:20: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 VAA29947 for ; Fri, 21 Sep 2001 21:20:40 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09409 for ; Fri, 21 Sep 2001 21:21:18 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8M1JB8P027185; Fri, 21 Sep 2001 21:19:11 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Sep 2001 21:20:10 -0400 Message-ID: From: Jonathan Rosenberg To: "'Scott Brim'" , midcom@ietf.org Subject: RE: [midcom] pre-midcom work item Date: Fri, 21 Sep 2001 21:20:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > -----Original Message----- > From: Scott Brim [mailto:swb@employees.org] > Sent: Friday, September 21, 2001 2:49 PM > To: midcom@ietf.org > Subject: Re: [midcom] pre-midcom work item > > > If you want to document "average current practice" that doesn't need a > working group, and I'd suggest that we stay out of it. Let those who > are practicing document it. > > If you want something new, that's an agreed-on standard, it will take > more than 4 weeks. I think what we want is an agreed upon standard. It can be done quickly, providing the following is true: 1. only people truly interested in seeing it completed in a timely fashion participate 2. a document that is 90% complete is chosen as the basis for moving forward, and peoples comments are delta changes from there, not fundamental arguments about its approach or feature set. I will be submitting a specification shortly that I think fits the bill; its a distillation of draft-rosenberg-sip-entfw-02 with input from others who have thought similarly. The relative simplicity of this protocol compared to lots of other things makes this a conceivable plan. I don't know about 4 weeks, but certainly in a matter of 1-2 months or so (i.e., before the next ietf) is feasible. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 21 21:34:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10251 for ; Fri, 21 Sep 2001 21:34: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 VAA00161; Fri, 21 Sep 2001 21:27: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 VAA00135 for ; Fri, 21 Sep 2001 21:27:45 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09494 for ; Fri, 21 Sep 2001 21:28:22 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8M1Q48P027240; Fri, 21 Sep 2001 21:26:06 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Sep 2001 21:27:03 -0400 Message-ID: From: Jonathan Rosenberg To: "'Randy Turner'" , Jonathan Rosenberg , "''Abdallah Rayhan' '" , "'Melinda Shore '" , "'midcom@ietf.org '" Subject: RE: [midcom] pre-midcom work item Date: Fri, 21 Sep 2001 21:27:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > -----Original Message----- > From: Randy Turner [mailto:rturner@2wire.com] > Sent: Friday, September 21, 2001 1:29 PM > To: 'Jonathan Rosenberg '; ''Abdallah Rayhan' '; 'Melinda Shore '; > 'midcom@ietf.org ' > Subject: RE: [midcom] pre-midcom work item > > > > > Hi Jonathan, > > In one your responses below, you are suggesting that MIDCOM > would not solve > the problem that this interim work would solve. So these two > solutions are > orthogonal? That would imply that MIDCOM would not supersede > this work at > some point, rather *both* would be needed. Its not a technology issue, so its hard to say. This protocol solves the cases where there is a nat which cannot (or the administrator will not) upgrade to support midcom, or allow it. How long will it be the case that there are nats which are not midcom enabled, or which are midcom enabled but this capability is disabled? I don't know. From a purely functional perspective, I don't think there is anyting in this new protocol that midcom cannot do. In fact, midcom does quite a lot more. Arguably, this more extensive functionality in midcom makes its security concerns more complex, which may make it ultimately hard to deploy in things like residential nats, where managing such security policies is hard. Since the new protocol can't "create" nat bindings to anything except the client that asked for the binding, the security implications are much less and easier to manage. > > I'm specifically talking about the point in the thread below: > > > > > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop > > the WGs from developing those standards. Why should we be > > the exception? > > need > midcom, and that hasn't changed. The fact is that midcom can't fully > solve > our problems.> > > Just looking for clarification, Hope the above answers the question. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat Sep 22 10: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 ESMTP id KAA01434 for ; Sat, 22 Sep 2001 10:46: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 KAA20916; Sat, 22 Sep 2001 10:38: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 KAA20885 for ; Sat, 22 Sep 2001 10:38:20 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01395 for ; Sat, 22 Sep 2001 10:38:19 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA22360 for ; Sat, 22 Sep 2001 09:37:52 -0500 (CDT) Received: from zsc4c000.us.nortel.com by smtprch2.nortel.com; Sat, 22 Sep 2001 09:31:26 -0500 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 22 Sep 2001 07:37:47 -0700 Message-ID: From: "Reinaldo Penno" To: "'Jonathan Rosenberg'" , "'Scott Brim'" , "'midcom@ietf.org'" Subject: RE: [midcom] pre-midcom work item Date: Sat, 22 Sep 2001 07:37:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14374.254E7290" 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_01C14374.254E7290 Content-Type: text/plain; charset="iso-8859-1" So, a few days ago our chair was saying rather emphatically we were not going to work on any MIDCOM protocol. Now we are going to work on a pre-midcom protocol which is highly questionable and might (no matter what some people say) preclude the development of MIDCOM altogether. So the solution might be not for carriers now, then after the first release we make some adjustments here and there and carry on...and bye bye midcom. Moreover what happened to the IETF's rough consensus? This seems to me more like a dictatorial regime than anything else. So, only people that agree with your ideas can participate (number 2 below) ? And only people which is "truly interested in seeing it completed in a timely fashion"? Timely for whom? IMO this needs much more discussion even if it doesn't fit someone's "agenda". -RP > I think what we want is an agreed upon standard. It can be > done quickly, > providing the following is true: > > 1. only people truly interested in seeing it completed in a > timely fashion > participate > 2. a document that is 90% complete is chosen as the basis for moving > forward, and peoples comments are delta changes from there, > not fundamental > arguments about its approach or feature set. > ------_=_NextPart_001_01C14374.254E7290 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] pre-midcom work item

So,

a few days ago our chair was saying rather = emphatically we were not going to work on any MIDCOM protocol. Now we = are going to work on a pre-midcom protocol which is highly questionable = and might (no matter what some people say) preclude the development of = MIDCOM altogether. So the solution might be not for carriers now, then = after the first release we make some adjustments here and there and = carry on...and bye bye midcom.

 
Moreover what happened to the IETF's rough = consensus? This seems to me more like a dictatorial regime than = anything else. 

So, only people that agree with your ideas can = participate (number 2 below) ? And only people which is "truly = interested in seeing it completed in a timely fashion"? Timely for = whom?

IMO this needs much more discussion even if it = doesn't fit someone's "agenda".

-RP
 

 
> I think what we want is an agreed upon = standard. It can be
> done quickly,
> providing the following is true:
>
> 1. only people truly interested in seeing it = completed in a
> timely fashion
> participate
> 2. a document that is 90% complete is chosen as = the basis for moving
> forward, and peoples comments are delta changes = from there,
> not fundamental
> arguments about its approach or feature = set.
>

 

------_=_NextPart_001_01C14374.254E7290-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat Sep 22 12:20: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 ESMTP id MAA02067 for ; Sat, 22 Sep 2001 12:20: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 MAA23171; Sat, 22 Sep 2001 12:14: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 MAA23142 for ; Sat, 22 Sep 2001 12:14:43 -0400 (EDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02024 for ; Sat, 22 Sep 2001 12:14:40 -0400 (EDT) Received: from ELEARW2K1 (sjc-vpn1-356.cisco.com [10.21.97.100]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA24309; Sat, 22 Sep 2001 09:14:13 -0700 (PDT) Message-ID: <000201c14381$9f5255e0$6921be18@cisco.com> From: "Eliot Lear" To: , "Melinda Shore" References: <5.1.0.14.0.20010921095614.00a74410@mira-sjc5-4.cisco.com> Subject: Re: [midcom] pre-midcom work item Date: Fri, 21 Sep 2001 12:08:00 -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.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 This boils down to additional protocol development in the form of a query to a server that returns some "netstat"-like information. The best question you can ask is, "Is anyone from my address (whatever that is) connecting to your transport X port Y?" This will work only if four things are true: 1. The remote side runs an additional server to provide the information; 2. The process asking on the other side is coordinating ALL connections of that type; and 3. The various NATs that are gone through don't do NPAT such that different IP addresses are used by the same host. 4. Any reverse NATs also answer the question, as opposed to servers behind them. There is a security consideration here. Others behind a NAT may ask the same question and get a response. ----- Original Message ----- From: "Melinda Shore" To: Sent: Friday, September 21, 2001 7:02 AM Subject: [midcom] pre-midcom work item > There has been considerable pressure for the IETF to come up > with a short-term approach to getting through firewalls and > NATs until midcom is available and widely deployed. Because of > that we've been asked to add a quick-turnaround deliverable to > our charter. The text of the charter addition will very likely > be tweaked, but currently looks something like: > > Ubiquitous deployment of midcom in all middleboxes could take many years. In > the interim, a solution is needed that allows applications to operate in the > presence of midcom-unaware middleboxes. To support this, the midcom group > will develop or document a protocol or approach that allows clients to > indirectly obtain address bindings from midcom-unaware middleboxes, through > communications with server elements on the public side of the middlebox. The > key goals for this effort are rapid delivery of a simple solution (since it > is an interim solution), consistency with the midcom framework, and > security. > > The proposed milestone date for this is October 2001 (i.e. next month). > > This would need to be accepted by the working group. If there are > objections or concerns please let us know ASAP. > > Thanks, > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sat Sep 22 12:26:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02112 for ; Sat, 22 Sep 2001 12:26: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 MAA23216; Sat, 22 Sep 2001 12:16: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 MAA23188 for ; Sat, 22 Sep 2001 12:16:52 -0400 (EDT) Received: from NREXCH.netrake.net (403217BC.ptr.dia.nextlink.net [64.50.23.188]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02031 for ; Sat, 22 Sep 2001 12:16:49 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [midcom] pre-midcom work item MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" x-mimeole: Produced By Microsoft Exchange V6.0.4417.0 Date: Sat, 22 Sep 2001 11:16:23 -0500 Message-ID: <7E06D3212981524CA10D2A114937C414073C0A@NREXCH.netrake.net> Thread-Topic: [midcom] pre-midcom work item Thread-Index: AcFDBvWKPQ1DOWIkRqOAyEmOxvy2lwAeeEDw From: "Ram Dantu" To: "Jonathan Rosenberg" , "Randy Turner" , "'Abdallah Rayhan' " , "Melinda Shore " , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA23189 Sender: 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 Jonathan, In the London Adhoc meeting, we are supposed to have a mailing list for NAT & FW traversal. Do we have one ? If so, can we please advertise on the midcom list. Thanks Ram Dantu Ph.D., Netrake Corporation 3000 Technology Drive, #100 Plano, Texas, 75074. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, September 21, 2001 8:27 PM To: 'Randy Turner'; Jonathan Rosenberg; ''Abdallah Rayhan' '; 'Melinda Shore '; 'midcom@ietf.org ' Subject: RE: [midcom] pre-midcom work item > -----Original Message----- > From: Randy Turner [mailto:rturner@2wire.com] > Sent: Friday, September 21, 2001 1:29 PM > To: 'Jonathan Rosenberg '; ''Abdallah Rayhan' '; 'Melinda Shore '; > 'midcom@ietf.org ' > Subject: RE: [midcom] pre-midcom work item > > > > > Hi Jonathan, > > In one your responses below, you are suggesting that MIDCOM > would not solve > the problem that this interim work would solve. So these two > solutions are > orthogonal? That would imply that MIDCOM would not supersede > this work at > some point, rather *both* would be needed. Its not a technology issue, so its hard to say. This protocol solves the cases where there is a nat which cannot (or the administrator will not) upgrade to support midcom, or allow it. How long will it be the case that there are nats which are not midcom enabled, or which are midcom enabled but this capability is disabled? I don't know. From a purely functional perspective, I don't think there is anyting in this new protocol that midcom cannot do. In fact, midcom does quite a lot more. Arguably, this more extensive functionality in midcom makes its security concerns more complex, which may make it ultimately hard to deploy in things like residential nats, where managing such security policies is hard. Since the new protocol can't "create" nat bindings to anything except the client that asked for the binding, the security implications are much less and easier to manage. > > I'm specifically talking about the point in the thread below: > > > > > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop > > the WGs from developing those standards. Why should we be > > the exception? > > need > midcom, and that hasn't changed. The fact is that midcom can't fully > solve > our problems.> > > Just looking for clarification, Hope the above answers the question. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 09:09:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03043 for ; Mon, 24 Sep 2001 09: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 IAA19908; Mon, 24 Sep 2001 08:59:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19881 for ; Mon, 24 Sep 2001 08:59:55 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00912 for ; Mon, 24 Sep 2001 08:59:46 -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 f8OCdQc19041 for ; Mon, 24 Sep 2001 05:39:26 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-98.cisco.com [10.82.192.98]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACE03098; Mon, 24 Sep 2001 05:39:06 -0700 (PDT) Message-Id: <5.1.0.14.0.20010924083656.00a8e100@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 24 Sep 2001 08:41:02 -0400 To: midcom From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Latest requirements bullets resolved Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org R1a: keep R10: fix up terminology, delete last sentence R13: delete R14: delete Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 09:09:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03087 for ; Mon, 24 Sep 2001 09:09: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 JAA20456; Mon, 24 Sep 2001 09:04: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 JAA20421 for ; Mon, 24 Sep 2001 09:04:43 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02069 for ; Mon, 24 Sep 2001 09:04:35 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8O5wH8P001057; Mon, 24 Sep 2001 01:58:17 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Sep 2001 01:59:18 -0400 Message-ID: From: Jonathan Rosenberg To: "'Eliot Lear'" , midcom@ietf.org, Melinda Shore Subject: RE: [midcom] pre-midcom work item Date: Mon, 24 Sep 2001 01:59:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Friday, September 21, 2001 3:08 PM > To: midcom@ietf.org; Melinda Shore > Subject: Re: [midcom] pre-midcom work item > > > This boils down to additional protocol development in the form of a > query to a server that returns some "netstat"-like information. > > The best question you can ask is, "Is anyone from my address (whatever > that is) connecting to your transport X port Y?" This will > work only if > four things are true: I'm not sure I follow. How does this help with nat traversal? Let me give a little detail on the kinds of things this new charter item is talking about. There are variations on the solutions, but there are a few common themes that can convey the basic idea. Consider a client that is behind a nat. It sends a request from a local socket, destined for some public server on the Internet. This server is hardly more than an echo server. It receives the request, and examines the source IP/port of that request. It places that information into the body of a response message that is sent back to the source IP/port where the request came from. The client now has the public address of the binding created by the nat for that request. If the nat is a "full cone" variant (the recommended type described in http://www.ietf.org/internet-drafts/draft-ietf-mmusic-natreq4udp-00.txt), any host on the public internet can send to this address/port, and it will arrive on the socket used to send this "echo" packet. So, the client uses that address in its application protocol (i.e., embedding it in the SDP of a SIP INVITE), and it is now capable of receiving media on it. Effectively, the client allocated a binding from its nat. It did that, not by talking TO the nat, but by talking THROUGH the nat. HTH, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 09:09:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03132 for ; Mon, 24 Sep 2001 09:09:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20488; Mon, 24 Sep 2001 09:04: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 JAA20429 for ; Mon, 24 Sep 2001 09:04:44 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02071 for ; Mon, 24 Sep 2001 09:04:35 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8O3wu8P000855; Sun, 23 Sep 2001 23:58:58 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sun, 23 Sep 2001 23:59:57 -0400 Message-ID: From: Jonathan Rosenberg To: Jonathan Rosenberg , "'Scott Brim'" , midcom@ietf.org Subject: RE: [midcom] pre-midcom work item Date: Sun, 23 Sep 2001 23:59:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, September 21, 2001 9:20 PM > To: 'Scott Brim'; midcom@ietf.org > Subject: RE: [midcom] pre-midcom work item > > > > If you want to document "average current practice" that > doesn't need a > > working group, and I'd suggest that we stay out of it. Let > those who > > are practicing document it. > > > > If you want something new, that's an agreed-on standard, it > will take > > more than 4 weeks. > > I think what we want is an agreed upon standard. It can be > done quickly, > providing the following is true: > > 1. only people truly interested in seeing it completed in a > timely fashion > participate > 2. a document that is 90% complete is chosen as the basis for moving > forward, and peoples comments are delta changes from there, > not fundamental > arguments about its approach or feature set. > > I will be submitting a specification shortly that I think > fits the bill; its > a distillation of draft-rosenberg-sip-entfw-02 with input > from others who > have thought similarly. I'd like to make an apology for my statements above. I did not mean in any way to imply any sort of dictatorial or totalitarian directions for the group, nor did I mean to imply that any document I would submit would have to be accepted or would be 90% done. My statements above do come across as seeming to imply that, and I am sorry. All I meant to say is that groups can make rapid process when there is strong consensus on a general approach, with a document that describes that agreed upon approach. Nothing more. As always, the decision to move forward is based on the consensus of the group, as is any agreement on a solution. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 09:15:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04828 for ; Mon, 24 Sep 2001 09:15: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 JAA20758; Mon, 24 Sep 2001 09:10: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 JAA20735 for ; Mon, 24 Sep 2001 09:10:27 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03253 for ; Mon, 24 Sep 2001 09:10:19 -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 f8OCh7g19038; Mon, 24 Sep 2001 05:43:07 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-98.cisco.com [10.82.192.98]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACE03153; Mon, 24 Sep 2001 05:45:04 -0700 (PDT) Message-Id: <5.1.0.14.0.20010924084125.00a961c0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 24 Sep 2001 08:47:00 -0400 To: "Reinaldo Penno" , "'midcom@ietf.org'" From: Melinda Shore Subject: RE: [midcom] pre-midcom work item 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:37 AM 9/22/01 -0700, Reinaldo Penno wrote: >a few days ago our chair was saying rather emphatically we were not going to work on any MIDCOM protocol. Now we are going to work on a pre-midcom protocol which is highly questionable and might (no matter what some people say) preclude the development of MIDCOM altogether. So the solution might be not for carriers now, then after the first release we make some adjustments here and there and carry on...and bye bye midcom. I think that's a bit of an overstatement. We cannot do midcom protocol development at this time because we really do not have agreement about fundamental issues related to topology, etc. We're trying to get those questions resolved. In the meantime what's being proposed for midcom is NOT protocol development (the protocol work that's been proposed is for SIP and SDP), but documentation of techniques that will work with modified SIP and SDP. I don't think anybody regards this as sufficient to address the same problem space in which midcom is working. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 09:42: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 ESMTP id JAA08602 for ; Mon, 24 Sep 2001 09:42: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 JAA22366; Mon, 24 Sep 2001 09:37: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 JAA22339 for ; Mon, 24 Sep 2001 09:37:02 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07919 for ; Mon, 24 Sep 2001 09:36:54 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12SY97; Mon, 24 Sep 2001 09:36:29 -0400 Message-Id: <3.0.5.32.20010924093522.008e9910@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 24 Sep 2001 09:35:22 -0400 To: Melinda Shore , midcom From: Mark Duffy Subject: Re: [midcom] Latest requirements bullets resolved In-Reply-To: <5.1.0.14.0.20010924083656.00a8e100@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 08:41 AM 9/24/01 -0400, Melinda Shore wrote: >R10: fix up terminology, delete last sentence Hi Melinda, Can you please clarify how the terminology is to be fixed? I presume you mean clarify the terms "Session creation, session termination". However, I saw 2 different understandings of what this is about during the discussion last week. Are we fixing it to clarify that these refer to the/a midcom session (I hope not) or to clarify that they refer to application sessions (microflows?) through the middlebox? Thanks, Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 10:21:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12569 for ; Mon, 24 Sep 2001 10:21: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 KAA23507; Mon, 24 Sep 2001 10:10: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 KAA23479 for ; Mon, 24 Sep 2001 10:10:09 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11534 for ; Mon, 24 Sep 2001 10:10:00 -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 f8OE9Xc10598; Mon, 24 Sep 2001 07:09:34 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-160.cisco.com [10.21.96.160]) by airborne.cisco.com (Mirapoint) with SMTP id AAA03441; Mon, 24 Sep 2001 07:09:31 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 24 Sep 2001 10:09:33 -0400 Date: Mon, 24 Sep 2001 10:09:33 -0400 From: Scott Brim To: Mark Duffy Cc: Melinda Shore , midcom Subject: Re: [midcom] Latest requirements bullets resolved Message-ID: <20010924100932.A1384@SBRIM-W2K> Mail-Followup-To: Scott Brim , Mark Duffy , Melinda Shore , midcom References: <5.1.0.14.0.20010924083656.00a8e100@mira-sjc5-4.cisco.com> <3.0.5.32.20010924093522.008e9910@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.20010924093522.008e9910@email.quarrytech.com>; from mduffy@quarrytech.com on Mon, Sep 24, 2001 at 09:35:22AM -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, Sep 24, 2001 09:35:22AM -0400, Mark Duffy allegedly wrote: > At 08:41 AM 9/24/01 -0400, Melinda Shore wrote: > >R10: fix up terminology, delete last sentence > > Hi Melinda, > Can you please clarify how the terminology is to be fixed? I presume you > mean clarify the terms "Session creation, session termination". However, I > saw 2 different understandings of what this is about during the discussion > last week. Are we fixing it to clarify that these refer to the/a midcom > session (I hope not) or to clarify that they refer to application sessions > (microflows?) through the middlebox? > Thanks, Mark How could a middlebox know anything about application sessions being created or terminating? The middlebox has no application intelligence anymore. Request for installation of a ruleset cannot be assumed to imply anything at a higher layer. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 10:27:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13228 for ; Mon, 24 Sep 2001 10:27: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 KAA23762; Mon, 24 Sep 2001 10:22: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 KAA23731 for ; Mon, 24 Sep 2001 10:22:38 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12654 for ; Mon, 24 Sep 2001 10:22:27 -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 f8OEK2g03078; Mon, 24 Sep 2001 07:20:02 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-98.cisco.com [10.82.192.98]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACG00856; Mon, 24 Sep 2001 07:22:00 -0700 (PDT) Message-Id: <5.1.0.14.0.20010924101702.00a8d5c0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 24 Sep 2001 10:23:55 -0400 To: Mark Duffy , midcom From: Melinda Shore Subject: Re: [midcom] Latest requirements bullets resolved In-Reply-To: <3.0.5.32.20010924093522.008e9910@email.quarrytech.com> References: <5.1.0.14.0.20010924083656.00a8e100@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 09:35 AM 9/24/01 -0400, Mark Duffy wrote: >Are we fixing it to clarify that these refer to the/a midcom >session (I hope not) or to clarify that they refer to application sessions >(microflows?) through the middlebox? Application sessions and "microflows" (still don't like that term for our purposes) aren't the same thing. We're trying to get application involvement out of middleboxes. Taking off the chair hat for a moment, the way I see it the middlebox should really only be notifying agents of events which affect that particular agent, whether it's a protocol failure of some sort, reboot, etc. I don't think that any notion of "session" we could come up with would be something that the middlebox ought to tell the agent about. My preference would be to drop the two "session" events entirely and reorganize the sentence so that it make it clearer that the protocol must allow the middlebox to notify the agent of significant events, such as ... Right now it's a little too much like an enumeration of events. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 10:58:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16170 for ; Mon, 24 Sep 2001 10:58: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 KAA25143; Mon, 24 Sep 2001 10:53: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 KAA25112 for ; Mon, 24 Sep 2001 10:53:38 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15571 for ; Mon, 24 Sep 2001 10:53:31 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12SZGA; Mon, 24 Sep 2001 10:53:06 -0400 Message-Id: <3.0.5.32.20010924105211.008bc100@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 24 Sep 2001 10:52:11 -0400 To: Scott Brim , Mark Duffy From: Mark Duffy Subject: Re: [midcom] Latest requirements bullets resolved Cc: Melinda Shore , midcom In-Reply-To: <20010924100932.A1384@SBRIM-W2K> References: <3.0.5.32.20010924093522.008e9910@email.quarrytech.com> <5.1.0.14.0.20010924083656.00a8e100@mira-sjc5-4.cisco.com> <3.0.5.32.20010924093522.008e9910@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 10:09 AM 9/24/01 -0400, Scott Brim wrote: >On Mon, Sep 24, 2001 09:35:22AM -0400, Mark Duffy allegedly wrote: >> At 08:41 AM 9/24/01 -0400, Melinda Shore wrote: >> >R10: fix up terminology, delete last sentence >> >> Hi Melinda, >> Can you please clarify how the terminology is to be fixed? I presume you >> mean clarify the terms "Session creation, session termination". However, I >> saw 2 different understandings of what this is about during the discussion >> last week. Are we fixing it to clarify that these refer to the/a midcom >> session (I hope not) or to clarify that they refer to application sessions >> (microflows?) through the middlebox? >> Thanks, Mark > >How could a middlebox know anything about application sessions being >created or terminating? The middlebox has no application intelligence >anymore. Request for installation of a ruleset cannot be assumed to >imply anything at a higher layer. While the middlebox should no longer need "application intelligence", my understanding is that it should still have "transport layer intelligence". E.g. it should be able to detect close of tcp sessions, detect which direction the connection is opened in, etc. And, probably it should be able to tell an agent that a ruleset has "expired" since the relevant transport connection has closed. If we instead interpret the language of R10 as referring to *midcom* sessions, a number of questions arise: Does the middlebox notify agents about sessions it has with other agents? I should think not. My understanding is that that would be out of scope. Does the middlebox notify an agent that its own session has been created or terminated? What would be the meaning of that? I understand this requirement (R10) to be about asynchronous notifications. I think other requirements (e.g R23, R34, R1a) cover the establishment and maintainance of the midcom agent between an agent and middlebox and presumably that mechanism is such that both ends can determine whether the session is there or not. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 11:08:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17289 for ; Mon, 24 Sep 2001 11:08: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 LAA25772; Mon, 24 Sep 2001 11:03: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 LAA25743 for ; Mon, 24 Sep 2001 11:03:46 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAC16775 for ; Mon, 24 Sep 2001 11:03:39 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12SZGV; Mon, 24 Sep 2001 11:03:15 -0400 Message-Id: <3.0.5.32.20010924110223.007fc400@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 24 Sep 2001 11:02:23 -0400 To: Melinda Shore , Mark Duffy , midcom From: Mark Duffy Subject: Re: [midcom] Latest requirements bullets resolved (R10) In-Reply-To: <5.1.0.14.0.20010924101702.00a8d5c0@mira-sjc5-4.cisco.com> References: <3.0.5.32.20010924093522.008e9910@email.quarrytech.com> <5.1.0.14.0.20010924083656.00a8e100@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 10:23 AM 9/24/01 -0400, Melinda Shore wrote: >At 09:35 AM 9/24/01 -0400, Mark Duffy wrote: >>Are we fixing it to clarify that these refer to the/a midcom >>session (I hope not) or to clarify that they refer to application sessions >>(microflows?) through the middlebox? > >Application sessions and "microflows" (still don't like that >term for our purposes) aren't the same thing. We're trying >to get application involvement out of middleboxes. Taking off >the chair hat for a moment, the way I see it the middlebox should >really only be notifying agents of events which affect that >particular agent, whether it's a protocol failure of some sort, >reboot, etc. I don't think that any notion of "session" we >could come up with would be something that the middlebox ought >to tell the agent about. My preference would be to drop the >two "session" events entirely and reorganize the sentence so >that it make it clearer that the protocol must allow the >middlebox to notify the agent of significant events, such as ... >Right now it's a little too much like an enumeration of events. > >Melinda OK. How about just dropping R10 entirely and we can cover this with R32, or some evolution of R32. ("R32: The protocol MUST support unsolicited messages, for event reporting and propagation of alarms.") _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 11:40:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19850 for ; Mon, 24 Sep 2001 11:40: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 LAA26768; Mon, 24 Sep 2001 11:33:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26739 for ; Mon, 24 Sep 2001 11:33:55 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19303 for ; Mon, 24 Sep 2001 11:33:47 -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 f8OFWpp13124 for ; Mon, 24 Sep 2001 11:32:51 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Mon, 24 Sep 2001 11:32:57 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Sep 2001 11:32:55 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110514FBA5@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Melinda Shore'" , Mark Duffy , midcom Subject: RE: [midcom] Latest requirements bullets resolved Date: Mon, 24 Sep 2001 11:32:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1450E.290ED0A0" 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_01C1450E.290ED0A0 Content-Type: text/plain; charset="iso-8859-1" At the very least one must speak of a security association between the middlebox and the agent. When you also talk about subscriptions to events, it is clear that the relationship extend beyond security. What has to be meant by "session", therefore, is the entire control relationship between a middlebox and a specific agent. -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Monday, September 24, 2001 10:24 AM To: Mark Duffy; midcom Subject: Re: [midcom] Latest requirements bullets resolved At 09:35 AM 9/24/01 -0400, Mark Duffy wrote: >Are we fixing it to clarify that these refer to the/a midcom >session (I hope not) or to clarify that they refer to application sessions >(microflows?) through the middlebox? Application sessions and "microflows" (still don't like that term for our purposes) aren't the same thing. We're trying to get application involvement out of middleboxes. Taking off the chair hat for a moment, the way I see it the middlebox should really only be notifying agents of events which affect that particular agent, whether it's a protocol failure of some sort, reboot, etc. I don't think that any notion of "session" we could come up with would be something that the middlebox ought to tell the agent about. My preference would be to drop the two "session" events entirely and reorganize the sentence so that it make it clearer that the protocol must allow the middlebox to notify the agent of significant events, such as ... Right now it's a little too much like an enumeration of events. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C1450E.290ED0A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Latest requirements bullets resolved

At the very least one must speak of a security = association between the middlebox and the agent.  When you also = talk about subscriptions to events, it is clear that the relationship = extend beyond security.  What has to be meant by = "session", therefore, is the entire control relationship = between a middlebox and a specific agent.

-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Monday, September 24, 2001 10:24 AM
To: Mark Duffy; midcom
Subject: Re: [midcom] Latest requirements bullets = resolved


At 09:35 AM 9/24/01 -0400, Mark Duffy wrote:
>Are we fixing it to clarify that these refer to = the/a midcom
>session (I hope not) or to clarify that they = refer to application sessions
>(microflows?) through  the = middlebox?

Application sessions and "microflows" = (still don't like that
term for our purposes) aren't the same thing.  = We're trying
to get application involvement out of = middleboxes.  Taking off
the chair hat for a moment, the way I see it the = middlebox should
really only be notifying agents of events which = affect that
particular agent, whether it's a protocol failure of = some sort,
reboot, etc.  I don't think that any notion of = "session" we
could come up with would be something that the = middlebox ought
to tell the agent about.  My preference would = be to drop the
two "session" events entirely and = reorganize the sentence so
that it make it clearer that the protocol must allow = the
middlebox to notify the agent of significant events, = such as ...
Right now it's a little too much like an enumeration = of events.

Melinda


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

------_=_NextPart_001_01C1450E.290ED0A0-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 12:14:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21420 for ; Mon, 24 Sep 2001 12:14: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 MAA28497; Mon, 24 Sep 2001 12:04: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 MAA28464 for ; Mon, 24 Sep 2001 12:04:11 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20926 for ; Mon, 24 Sep 2001 12:04:04 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A9775EE80398; Mon, 24 Sep 2001 12:04:07 -0400 Message-ID: <001b01c14512$4bcae300$2300000a@acmepacket.com> From: "Bob Penfield" To: "Mark Duffy" , "midcom" , "Melinda Shore" References: <5.1.0.14.0.20010924083656.00a8e100@mira-sjc5-4.cisco.com> <5.1.0.14.0.20010924101702.00a8d5c0@mira-sjc5-4.cisco.com> Subject: Re: [midcom] Latest requirements bullets resolved Date: Mon, 24 Sep 2001 12:02:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.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 In that particular requirement (R10), I am fairly sure that the term session was being used in its NAT context where is really does mean "flow" (or "microflow") and not "application session". In any event, the requirement that I have (and I'm sure others share this) is that the protocol include a means for the middlebox to notify the midcom agents when particular events relative to a ruleset occur. This includes things like timeout and termination. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Melinda Shore" To: "Mark Duffy" ; "midcom" Sent: Monday, September 24, 2001 10:23 AM Subject: Re: [midcom] Latest requirements bullets resolved > At 09:35 AM 9/24/01 -0400, Mark Duffy wrote: > >Are we fixing it to clarify that these refer to the/a midcom > >session (I hope not) or to clarify that they refer to application sessions > >(microflows?) through the middlebox? > > Application sessions and "microflows" (still don't like that > term for our purposes) aren't the same thing. We're trying > to get application involvement out of middleboxes. Taking off > the chair hat for a moment, the way I see it the middlebox should > really only be notifying agents of events which affect that > particular agent, whether it's a protocol failure of some sort, > reboot, etc. I don't think that any notion of "session" we > could come up with would be something that the middlebox ought > to tell the agent about. My preference would be to drop the > two "session" events entirely and reorganize the sentence so > that it make it clearer that the protocol must allow the > middlebox to notify the agent of significant events, such as ... > Right now it's a little too much like an enumeration of events. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 12:34:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22281 for ; Mon, 24 Sep 2001 12:34: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 MAA29300; Mon, 24 Sep 2001 12:27: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 MAA29273 for ; Mon, 24 Sep 2001 12:27:42 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22033 for ; Mon, 24 Sep 2001 12:27:34 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AEFD730B0398; Mon, 24 Sep 2001 12:27:41 -0400 Message-ID: <000f01c14515$965ea7a0$2300000a@acmepacket.com> From: "Bob Penfield" To: "midcom mail-list" Date: Mon, 24 Sep 2001 12:25:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [midcom] reqs bullets - R40 Sender: 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 Item R40 should be deleted. It is almost identical to R11 which was rejected in favor of R82. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 12:34:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22311 for ; Mon, 24 Sep 2001 12:34: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 MAA29415; Mon, 24 Sep 2001 12:30: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 MAA29369 for ; Mon, 24 Sep 2001 12:30:05 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22118 for ; Mon, 24 Sep 2001 12:29:56 -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 f8OGTXu08229 for ; Mon, 24 Sep 2001 09:29:33 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-160.cisco.com [10.21.96.160]) by airborne.cisco.com (Mirapoint) with SMTP id AAB01213; Mon, 24 Sep 2001 09:29:31 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 24 Sep 2001 12:29:32 -0400 Date: Mon, 24 Sep 2001 12:29:32 -0400 From: Scott Brim To: midcom Subject: Re: [midcom] Latest requirements bullets resolved Message-ID: <20010924122932.F1384@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom References: <5.1.0.14.0.20010924083656.00a8e100@mira-sjc5-4.cisco.com> <5.1.0.14.0.20010924101702.00a8d5c0@mira-sjc5-4.cisco.com> <001b01c14512$4bcae300$2300000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001b01c14512$4bcae300$2300000a@acmepacket.com>; from bpenfield@acmepacket.com on Mon, Sep 24, 2001 at 12:02:21PM -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, Sep 24, 2001 12:02:21PM -0400, Bob Penfield allegedly wrote: > In that particular requirement (R10), I am fairly sure that the term session > was being used in its NAT context where is really does mean "flow" (or > "microflow") and not "application session". In that case let's delete it. > In any event, the requirement > that I have (and I'm sure others share this) is that the protocol include a > means for the middlebox to notify the midcom agents when particular events > relative to a ruleset occur. This includes things like timeout and > termination. You want to know when a ruleset timer expires? But you're the one who set it. What is 'termination'? _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 12:40:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22627 for ; Mon, 24 Sep 2001 12:40: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 MAA29822; Mon, 24 Sep 2001 12:35: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 MAA29787 for ; Mon, 24 Sep 2001 12:35:21 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22357 for ; Mon, 24 Sep 2001 12:35:13 -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 f8OGZ3A13806; Mon, 24 Sep 2001 09:35:03 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-98.cisco.com [10.82.192.98]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACG04258; Mon, 24 Sep 2001 09:34:32 -0700 (PDT) Message-Id: <5.1.0.14.0.20010924123246.00a89780@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 24 Sep 2001 12:36:26 -0400 To: Mark Duffy , midcom From: Melinda Shore Subject: Re: [midcom] Latest requirements bullets resolved (R10) In-Reply-To: <3.0.5.32.20010924110223.007fc400@email.quarrytech.com> References: <5.1.0.14.0.20010924101702.00a8d5c0@mira-sjc5-4.cisco.com> <3.0.5.32.20010924093522.008e9910@email.quarrytech.com> <5.1.0.14.0.20010924083656.00a8e100@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 11:02 AM 9/24/01 -0400, Mark Duffy wrote: >OK. How about just dropping R10 entirely and we can cover this with R32, >or some evolution of R32. ("R32: The protocol MUST support unsolicited >messages, for event reporting and propagation of alarms.") I'm always delighted to have a concrete proposal and I like this one, with the caveat that R32 isn't yet accepted and that we should get some text in place for R32. We need to be sure that the intended requirement is covered. If someone has some proposed text to cover this, please post it. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 12:55:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23523 for ; Mon, 24 Sep 2001 12:55: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 MAA00167; Mon, 24 Sep 2001 12:51: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 MAA00136 for ; Mon, 24 Sep 2001 12:51:04 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23300 for ; Mon, 24 Sep 2001 12:50:55 -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 f8OGoXc18705 for ; Mon, 24 Sep 2001 09:50:33 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-160.cisco.com [10.21.96.160]) by airborne.cisco.com (Mirapoint) with SMTP id AAB01599; Mon, 24 Sep 2001 09:50:32 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 24 Sep 2001 12:50:32 -0400 Date: Mon, 24 Sep 2001 12:50:32 -0400 From: Scott Brim To: midcom mail-list Subject: Re: [midcom] reqs bullets - R40 Message-ID: <20010924125032.G1384@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom mail-list References: <000f01c14515$965ea7a0$2300000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000f01c14515$965ea7a0$2300000a@acmepacket.com>; from bpenfield@acmepacket.com on Mon, Sep 24, 2001 at 12:25:54PM -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, Sep 24, 2001 12:25:54PM -0400, Bob Penfield allegedly wrote: > Item R40 should be deleted. It is almost identical to R11 which was rejected > in favor of R82. Agreed. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 13:29:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25062 for ; Mon, 24 Sep 2001 13:29:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00859; Mon, 24 Sep 2001 13:17:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00828 for ; Mon, 24 Sep 2001 13:17:22 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24536 for ; Mon, 24 Sep 2001 13:17:14 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AA9F9A960398; Mon, 24 Sep 2001 13:17:19 -0400 Message-ID: <002701c1451c$848cb7e0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Scott Brim" , "midcom" References: <5.1.0.14.0.20010924083656.00a8e100@mira-sjc5-4.cisco.com> <5.1.0.14.0.20010924101702.00a8d5c0@mira-sjc5-4.cisco.com> <001b01c14512$4bcae300$2300000a@acmepacket.com> <20010924122932.F1384@SBRIM-W2K> Subject: Re: [midcom] Latest requirements bullets resolved Date: Mon, 24 Sep 2001 13:15:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit As Mark stated, if a particular type of middlebox is "aware" of a TCP connection being terminated, it could tell the midcom agent. As far as the ruleset timer, why should I time the ruleset in the midcom agent if the middlebox is doing it for me? The midcom agent needs the middlebox to tell it when the rule has expired so that it can take care of the application state. For VOIP with SIP, you might have an "inactivity timer" to solve the so called "Lost BYE" problem. If the middlebox is capable of detecting that no more packets for a given ruleset are traversing the middlebox for some specified period of time, it could tell the midcom agent which could then terminate the application session. There will likely be a variety of events that occur in the middlebox that the midcom agent wants to know about. If this is covered by R32, then we can delete R10. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Scott Brim" To: "midcom" Sent: Monday, September 24, 2001 12:29 PM Subject: Re: [midcom] Latest requirements bullets resolved > On Mon, Sep 24, 2001 12:02:21PM -0400, Bob Penfield allegedly wrote: > > In that particular requirement (R10), I am fairly sure that the term session > > was being used in its NAT context where is really does mean "flow" (or > > "microflow") and not "application session". > > In that case let's delete it. > > > In any event, the requirement > > that I have (and I'm sure others share this) is that the protocol include a > > means for the middlebox to notify the midcom agents when particular events > > relative to a ruleset occur. This includes things like timeout and > > termination. > > You want to know when a ruleset timer expires? But you're the one who > set it. What is 'termination'? > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 14:01:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26470 for ; Mon, 24 Sep 2001 14:01: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 NAA01891; Mon, 24 Sep 2001 13:56: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 NAA01858 for ; Mon, 24 Sep 2001 13:56:54 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26307 for ; Mon, 24 Sep 2001 13:56:46 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12SZX5; Mon, 24 Sep 2001 13:56:23 -0400 Message-Id: <3.0.5.32.20010924135504.007d75c0@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 24 Sep 2001 13:55:04 -0400 To: Scott Brim , midcom mail-list From: Mark Duffy Subject: Re: [midcom] reqs bullets - R40 In-Reply-To: <20010924125032.G1384@SBRIM-W2K> References: <000f01c14515$965ea7a0$2300000a@acmepacket.com> <000f01c14515$965ea7a0$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 12:50 PM 9/24/01 -0400, Scott Brim wrote: >On Mon, Sep 24, 2001 12:25:54PM -0400, Bob Penfield allegedly wrote: >> Item R40 should be deleted. It is almost identical to R11 which was rejected >> in favor of R82. > >Agreed. I agree as well. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 14:02:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26492 for ; Mon, 24 Sep 2001 14:02: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 NAA01942; Mon, 24 Sep 2001 13:57: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 NAA01917 for ; Mon, 24 Sep 2001 13:57:45 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26334 for ; Mon, 24 Sep 2001 13:57:36 -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 MAA04106 for ; Mon, 24 Sep 2001 12:57:05 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 24 Sep 2001 12:56:55 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Sep 2001 12:56:41 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F186@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Scott Brim'" , midcom Subject: RE: [midcom] Latest requirements bullets resolved Date: Mon, 24 Sep 2001 12:56:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14522.43197130" Sender: 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_01C14522.43197130 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Scott Brim [mailto:swb@employees.org] > Sent: Monday, September 24, 2001 11:30 AM > To: midcom > Subject: Re: [midcom] Latest requirements bullets resolved > > > > You want to know when a ruleset timer expires? But you're the one who > set it. The Midcom Agent may not want to maintain the timer state. It may just want to install a timer state in the MB and be notified when the timer expires & react to that notification with specific activities. ------_=_NextPart_001_01C14522.43197130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Latest requirements bullets resolved

> -----Original Message-----
> From: Scott Brim [mailto:swb@employees.org]
> Sent: Monday, September 24, 2001 11:30 = AM
> To: midcom
> Subject: Re: [midcom] Latest requirements = bullets resolved
>
>
>
> You want to know when a ruleset timer = expires?  But you're the one who
> set it. 

The Midcom Agent may not want to maintain the timer = state. It may just want to install a timer state in the MB and be = notified when the timer expires & react to that notification with = specific activities.

------_=_NextPart_001_01C14522.43197130-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 14:10:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26749 for ; Mon, 24 Sep 2001 14:10: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 OAA02501; Mon, 24 Sep 2001 14:05: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 OAA02472 for ; Mon, 24 Sep 2001 14:05:16 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26595 for ; Mon, 24 Sep 2001 14:05:07 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12SZYS; Mon, 24 Sep 2001 14:04:45 -0400 Message-Id: <3.0.5.32.20010924140351.007c1500@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 24 Sep 2001 14:03:51 -0400 To: Melinda Shore , midcom From: Mark Duffy Subject: Re: [midcom] Latest requirements bullets resolved (R10) In-Reply-To: <5.1.0.14.0.20010924123246.00a89780@mira-sjc5-4.cisco.com> References: <3.0.5.32.20010924110223.007fc400@email.quarrytech.com> <5.1.0.14.0.20010924101702.00a8d5c0@mira-sjc5-4.cisco.com> <3.0.5.32.20010924093522.008e9910@email.quarrytech.com> <5.1.0.14.0.20010924083656.00a8e100@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:36 PM 9/24/01 -0400, Melinda Shore wrote: >At 11:02 AM 9/24/01 -0400, Mark Duffy wrote: >>OK. How about just dropping R10 entirely and we can cover this with R32, >>or some evolution of R32. ("R32: The protocol MUST support unsolicited >>messages, for event reporting and propagation of alarms.") > >I'm always delighted to have a concrete proposal and I like this >one, with the caveat that R32 isn't yet accepted and that we should >get some text in place for R32. We need to be sure that the intended >requirement is covered. > >If someone has some proposed text to cover this, please post it. > >Thanks, > >Melinda Old R32: The protocol MUST support unsolicited messages, for event reporting and propagation of alarms. Proposed R32: The protocol MUST support unsolicited messages from middlebox to agent, for reporting conditions detected asynchronously at the middlebox. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 14:11:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26771 for ; Mon, 24 Sep 2001 14:11: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 OAA02574; Mon, 24 Sep 2001 14:07: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 OAA02545 for ; Mon, 24 Sep 2001 14:07:11 -0400 (EDT) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26656 for ; Mon, 24 Sep 2001 14:07:02 -0400 (EDT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GK6003KHI9RDC@firewall.wcom.com> for midcom@ietf.org; Mon, 24 Sep 2001 18:05:52 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GK600M01I9KZM@dgismtp04.wcomnet.com> for midcom@ietf.org; Mon, 24 Sep 2001 18:05:51 +0000 (GMT) Received: from rccc6131 ([166.35.224.112]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GK600M0HI91Q4@dgismtp04.wcomnet.com> for midcom@ietf.org; Mon, 24 Sep 2001 18:05:26 +0000 (GMT) Date: Mon, 24 Sep 2001 13:05:18 -0500 From: "Christopher A. Martin" Subject: RE: [midcom] reqs bullets - R40 In-reply-to: <3.0.5.32.20010924135504.007d75c0@email.quarrytech.com> To: "'midcom mail-list'" Reply-to: christopher.a.martin@wcom.com Message-id: <002a01c14523$78c2f8a0$70e023a6@rccc6131.mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Agree > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Mark Duffy > Sent: Monday, September 24, 2001 12:55 PM > To: Scott Brim; midcom mail-list > Subject: Re: [midcom] reqs bullets - R40 > > > At 12:50 PM 9/24/01 -0400, Scott Brim wrote: > >On Mon, Sep 24, 2001 12:25:54PM -0400, Bob Penfield allegedly wrote: > >> Item R40 should be deleted. It is almost identical to R11 which was > rejected > >> in favor of R82. > > > >Agreed. > I agree as well. > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 14:12:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26795 for ; Mon, 24 Sep 2001 14:12: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 OAA02624; Mon, 24 Sep 2001 14:08: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 OAA02593 for ; Mon, 24 Sep 2001 14:08:04 -0400 (EDT) Received: from web14302.mail.yahoo.com (web14302.mail.yahoo.com [216.136.173.78]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26697 for ; Mon, 24 Sep 2001 14:07:50 -0400 (EDT) Message-ID: <20010924180758.46484.qmail@web14302.mail.yahoo.com> Received: from [207.164.4.36] by web14302.mail.yahoo.com via HTTP; Mon, 24 Sep 2001 14:07:58 EDT Date: Mon, 24 Sep 2001 14:07:58 -0400 (EDT) From: Abdallah Rayhan Subject: RE: [midcom] pre-midcom work item To: Melinda Shore , Reinaldo Penno , "'midcom@ietf.org'" In-Reply-To: <5.1.0.14.0.20010924084125.00a961c0@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 --- Melinda Shore wrote: > At 07:37 AM 9/22/01 -0700, Reinaldo Penno wrote: > >a few days ago our chair was saying rather emphatically we were not > going to work on any MIDCOM protocol. Now we are going to work on a > pre-midcom protocol which is highly questionable and might (no matter > what some people say) preclude the development of MIDCOM altogether. > So the solution might be not for carriers now, then after the first > release we make some adjustments here and there and carry on...and > bye bye midcom. > > I think that's a bit of an overstatement. We cannot do midcom > protocol development at this time because we really do not have > agreement about fundamental issues related to topology, etc. > We're trying to get those questions resolved. > > In the meantime what's being proposed for midcom is NOT protocol > development (the protocol work that's been proposed is for SIP and > SDP), but documentation of techniques that will work with modified > SIP and SDP. I don't think anybody regards this as sufficient to > address the same problem space in which midcom is working. This is what I find hard to understand. When we were discussing the charter of this WG, there was an agreement to leave the protocol discussion out of it for the time being till we are sure where we are heading to. Now instead if amending the charter to develop the protocol, it is being argued to amend the charter for a pre-midcom protocol. Are we going backward in our development and/or letting biz practices dictate our deliverables and divert our effort to something that is supposed to be interim, yet create more controversial. regards Abdallah _______________________________________________________ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 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 ESMTP id OAA26832 for ; Mon, 24 Sep 2001 14:15: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 OAA02786; Mon, 24 Sep 2001 14:10: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 OAA02755 for ; Mon, 24 Sep 2001 14:10:58 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26761 for ; Mon, 24 Sep 2001 14:10:48 -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 f8OIAQc07594 for ; Mon, 24 Sep 2001 11:10:26 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-160.cisco.com [10.21.96.160]) by airborne.cisco.com (Mirapoint) with SMTP id AAC01270; Mon, 24 Sep 2001 11:10:24 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 24 Sep 2001 14:10:24 -0400 Date: Mon, 24 Sep 2001 14:10:24 -0400 From: Scott Brim To: midcom Subject: Re: [midcom] Latest requirements bullets resolved Message-ID: <20010924141024.I1384@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom References: <933FADF5E673D411B8A30002A5608A0E06F186@zrc2c012.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <933FADF5E673D411B8A30002A5608A0E06F186@zrc2c012.us.nortel.com>; from sanjoy@nortelnetworks.com on Mon, Sep 24, 2001 at 12:56:40PM -0500 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Mon, Sep 24, 2001 12:56:40PM -0500, Sanjoy Sen allegedly wrote: > > You want to know when a ruleset timer expires? But you're the one who > > set it. > > The Midcom Agent may not want to maintain the timer state. It may just want > to install a timer state in the MB and be notified when the timer expires & > react to that notification with specific activities. This is a months-old argument, about where to put the complexity. Recent trends seem to be to pile complexity in the agent and keep the middlebox simple -- viz. the example of a simple bump-in-the-wire firewall, and the tendency to bundle application proxies with midcom agents. That's evidence of where people seem to want to go. I also think it's a safer base for the future to keep control state complexity in the controller, not the controlled object. That's about fate-sharing and "ownership" of state. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 14:17: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 ESMTP id OAA26882 for ; Mon, 24 Sep 2001 14:17: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 OAA02906; Mon, 24 Sep 2001 14:15: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 OAA02871 for ; Mon, 24 Sep 2001 14:15:34 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26845 for ; Mon, 24 Sep 2001 14:15:24 -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 f8OIF0u13017; Mon, 24 Sep 2001 11:15:01 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-98.cisco.com [10.82.192.98]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACI01767; Mon, 24 Sep 2001 11:14:58 -0700 (PDT) Message-Id: <5.1.0.14.0.20010924141554.00a9c4a0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 24 Sep 2001 14:16:50 -0400 To: Abdallah Rayhan , "'midcom@ietf.org'" From: Melinda Shore Subject: RE: [midcom] pre-midcom work item In-Reply-To: <20010924180758.46484.qmail@web14302.mail.yahoo.com> References: <5.1.0.14.0.20010924084125.00a961c0@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:07 PM 9/24/01 -0400, Abdallah Rayhan wrote: >Now instead if amending >the charter to develop the protocol, it is being argued to >amend the charter for a pre-midcom protocol. Again, the proposed addition is NOT to do protocol development. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 14: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 ESMTP id OAA27068 for ; Mon, 24 Sep 2001 14:23: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 OAA03084; Mon, 24 Sep 2001 14:21:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03056 for ; Mon, 24 Sep 2001 14:21:23 -0400 (EDT) Received: from web14301.mail.yahoo.com (web14301.mail.yahoo.com [216.136.173.77]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27016 for ; Mon, 24 Sep 2001 14:21:14 -0400 (EDT) Message-ID: <20010924182121.5616.qmail@web14301.mail.yahoo.com> Received: from [207.164.4.36] by web14301.mail.yahoo.com via HTTP; Mon, 24 Sep 2001 14:21:21 EDT Date: Mon, 24 Sep 2001 14:21:21 -0400 (EDT) From: Abdallah Rayhan Subject: RE: [midcom] pre-midcom work item To: Jonathan Rosenberg , Melinda Shore , 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 --- Jonathan Rosenberg wrote: > > Secondly, this introduces > > new architectural constraints that is going to screw > > the consensus achieved so far on the architecture draft. > > How is that? Before amending the charter we at least need to know what and how this would work. Instead we got a charter change dictated on us before learning how this SIP-happy-NAT is going to influence the current architecture, or being discussed and scrutinized by the WG. > > > > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop > > the WGs from developing those standards. Why should we be > > the exception? > > No one is saying that it should not be deployed. Full steam ahead. We > need > midcom, and that hasn't changed. The fact is that midcom can't fully > solve > our problems. > > Its also worth noting that there are already solutions being deployed > today > that play the role of the proposed addition. Those are all > proprietary and > not interoperable. Let us not let that continue. What will happen is another beast will be added to the gang. _______________________________________________________ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 15:42: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 ESMTP id PAA28918 for ; Mon, 24 Sep 2001 15:42: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 PAA05185; Mon, 24 Sep 2001 15: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 PAA05158 for ; Mon, 24 Sep 2001 15:41:15 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28892 for ; Mon, 24 Sep 2001 15:41:07 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA10949 for ; Mon, 24 Sep 2001 14:40:40 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 24 Sep 2001 14:33:18 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Sep 2001 14:39:38 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F187@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Scott Brim'" , midcom Subject: RE: [midcom] Latest requirements bullets resolved Date: Mon, 24 Sep 2001 14:39:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14530.A3F00F10" 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_01C14530.A3F00F10 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Scott Brim [mailto:swb@employees.org] > Sent: Monday, September 24, 2001 1:10 PM > To: midcom > Subject: Re: [midcom] Latest requirements bullets resolved > > > On Mon, Sep 24, 2001 12:56:40PM -0500, Sanjoy Sen allegedly wrote: > > > You want to know when a ruleset timer expires? But > you're the one who > > > set it. > > > > The Midcom Agent may not want to maintain the timer state. > It may just want > > to install a timer state in the MB and be notified when the > timer expires & > > react to that notification with specific activities. > > This is a months-old argument, about where to put the complexity. > Recent trends seem to be to pile complexity in the agent and keep the > middlebox simple -- viz. the example of a simple bump-in-the-wire > firewall, and the tendency to bundle application proxies with midcom > agents. That's evidence of where people seem to want to go. I also > think it's a safer base for the future to keep control state > complexity > in the controller, not the controlled object. That's about > fate-sharing > and "ownership" of state. > If I remember correctly, people actually thought that there was no need for the Agent to maintain the timer state as they'll be maintained by the MB anyway (what's the purpose of reqmts R6 & R81? What if the Agent dies after installing a ruleset?). If the MA is not keeping timer state, how would it know when to refresh the ruleset unless notified by the MB? ------_=_NextPart_001_01C14530.A3F00F10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Latest requirements bullets resolved

> -----Original Message-----
> From: Scott Brim [mailto:swb@employees.org]
> Sent: Monday, September 24, 2001 1:10 PM
> To: midcom
> Subject: Re: [midcom] Latest requirements = bullets resolved
>
>
> On Mon, Sep 24, 2001 12:56:40PM -0500, Sanjoy = Sen allegedly wrote:
> > > You want to know when a ruleset timer = expires?  But
> you're the one who
> > > set it. 
> >
> > The Midcom Agent may not want to maintain = the timer state.
> It may just want
> > to install a timer state in the MB and be = notified when the
> timer expires &
> > react to that notification with specific = activities.
>
> This is a months-old argument, about where to = put the complexity.
> Recent trends seem to be to pile complexity in = the agent and keep the
> middlebox simple -- viz. the example of a = simple bump-in-the-wire
> firewall, and the tendency to bundle = application proxies with midcom
> agents.  That's evidence of where people = seem to want to go.  I also
> think it's a safer base for the future to keep = control state
> complexity
> in the controller, not the controlled = object.  That's about
> fate-sharing
> and "ownership" of state.
>

If I remember correctly, people actually thought that = there was no need for the Agent to maintain the timer state as they'll = be maintained by the MB anyway (what's the purpose of reqmts R6 & = R81? What if the Agent dies after installing a ruleset?). If the MA is = not keeping timer state, how would it know when to refresh the ruleset = unless notified by the MB?  

------_=_NextPart_001_01C14530.A3F00F10-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Mon Sep 24 16:03: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 ESMTP id QAA29415 for ; Mon, 24 Sep 2001 16:03: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 QAA05762; Mon, 24 Sep 2001 16:00: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 QAA05726 for ; Mon, 24 Sep 2001 16:00:27 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29306 for ; Mon, 24 Sep 2001 16:00:19 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12S5CL; Mon, 24 Sep 2001 15:59:55 -0400 Message-Id: <3.0.5.32.20010924155903.00882100@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 24 Sep 2001 15:59:03 -0400 To: Scott Brim , midcom From: Mark Duffy Subject: Re: [midcom] Latest requirements bullets resolved In-Reply-To: <20010924141024.I1384@SBRIM-W2K> References: <933FADF5E673D411B8A30002A5608A0E06F186@zrc2c012.us.nortel.com> <933FADF5E673D411B8A30002A5608A0E06F186@zrc2c012.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 At 02:10 PM 9/24/01 -0400, Scott Brim wrote: >On Mon, Sep 24, 2001 12:56:40PM -0500, Sanjoy Sen allegedly wrote: >> > You want to know when a ruleset timer expires? But you're the one who >> > set it. >> >> The Midcom Agent may not want to maintain the timer state. It may just want >> to install a timer state in the MB and be notified when the timer expires & >> react to that notification with specific activities. > >This is a months-old argument, about where to put the complexity. >Recent trends seem to be to pile complexity in the agent and keep the >middlebox simple -- viz. the example of a simple bump-in-the-wire >firewall, and the tendency to bundle application proxies with midcom >agents. That's evidence of where people seem to want to go. I also >think it's a safer base for the future to keep control state complexity >in the controller, not the controlled object. That's about fate-sharing >and "ownership" of state. I believe that midcom should permit/support transport-layer aware middleboxes. This involves, for example, the ability for an agent to tell a mb to install a ruleset for a particular tcp n-tuple that must originate in a certain direction and that is to permit packet flow in both directions from the time the tcp connection is established until it is brought down, and no more packets thereafter. This is not a philosophical choice about where to put the complexity. If a scenario involves a media flow that does not pass through the agent, the agent cannot inspect the transport connection state. Even if the flow passes through the agent, it is likely that the agent hardware is not optimized for this type of inspection. On the other hand, this is exactly the sort of behaviour that firewalls and NATs are designed for and exhibit *today*. i think we have agreed that port numbers are part of the filter spec. That to me implies that the middlebox may be "transport layer aware". I view that awareness as not limited to static awareness of the transport layer but also allowing for stateful awareness. -Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 25 09:48:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03266 for ; Tue, 25 Sep 2001 09:48: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 JAA08383; Tue, 25 Sep 2001 09:46:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08349 for ; Tue, 25 Sep 2001 09:46:21 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03188 for ; Tue, 25 Sep 2001 09:46:16 -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 f8PDhc507732 for ; Tue, 25 Sep 2001 06:43:41 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn2-99.cisco.com [10.21.112.99]) by airborne.cisco.com (Mirapoint) with SMTP id AAC13349; Tue, 25 Sep 2001 06:45:37 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Tue, 25 Sep 2001 09:45:37 -0400 Date: Tue, 25 Sep 2001 09:45:36 -0400 From: Scott Brim To: midcom mail-list Message-ID: <20010925094536.A1268@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom mail-list Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [midcom] new bullets text Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Bullets -010924.txt is now available at . R1a accepted. R32 revised and accepted. R10 deleted in favor of R32. R13 deleted. R14 deleted. R40 deleted in favor of R82. Progress is being made. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 25 09:48:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03276 for ; Tue, 25 Sep 2001 09:48: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 JAA08314; Tue, 25 Sep 2001 09:45: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 JAA08242 for ; Tue, 25 Sep 2001 09:45:07 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03137 for ; Tue, 25 Sep 2001 09:45:01 -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 f8PDhnp26674 for ; Tue, 25 Sep 2001 09:43:49 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Tue, 25 Sep 2001 09:43:58 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Sep 2001 09:43:57 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110514FBAD@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Mark Duffy'" , Scott Brim , midcom Subject: RE: [midcom] Latest requirements bullets resolved Date: Tue, 25 Sep 2001 09:43:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C145C8.1AB96D20" 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_01C145C8.1AB96D20 Content-Type: text/plain; charset="iso-8859-1" This seems to be suggesting a requirement for an "end of flow" event notification. -----Original Message----- From: Mark Duffy [mailto:mduffy@quarrytech.com] Sent: Monday, September 24, 2001 3:59 PM To: Scott Brim; midcom Subject: Re: [midcom] Latest requirements bullets resolved At 02:10 PM 9/24/01 -0400, Scott Brim wrote: >On Mon, Sep 24, 2001 12:56:40PM -0500, Sanjoy Sen allegedly wrote: >> > You want to know when a ruleset timer expires? But you're the one who >> > set it. >> >> The Midcom Agent may not want to maintain the timer state. It may just want >> to install a timer state in the MB and be notified when the timer expires & >> react to that notification with specific activities. > >This is a months-old argument, about where to put the complexity. >Recent trends seem to be to pile complexity in the agent and keep the >middlebox simple -- viz. the example of a simple bump-in-the-wire >firewall, and the tendency to bundle application proxies with midcom >agents. That's evidence of where people seem to want to go. I also >think it's a safer base for the future to keep control state complexity >in the controller, not the controlled object. That's about fate-sharing >and "ownership" of state. I believe that midcom should permit/support transport-layer aware middleboxes. This involves, for example, the ability for an agent to tell a mb to install a ruleset for a particular tcp n-tuple that must originate in a certain direction and that is to permit packet flow in both directions from the time the tcp connection is established until it is brought down, and no more packets thereafter. This is not a philosophical choice about where to put the complexity. If a scenario involves a media flow that does not pass through the agent, the agent cannot inspect the transport connection state. Even if the flow passes through the agent, it is likely that the agent hardware is not optimized for this type of inspection. On the other hand, this is exactly the sort of behaviour that firewalls and NATs are designed for and exhibit *today*. i think we have agreed that port numbers are part of the filter spec. That to me implies that the middlebox may be "transport layer aware". I view that awareness as not limited to static awareness of the transport layer but also allowing for stateful awareness. -Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C145C8.1AB96D20 Content-Type: text/html; charset="iso-8859-1" RE: [midcom] Latest requirements bullets resolved

This seems to be suggesting a requirement for an "end of flow" event notification.

-----Original Message-----
From: Mark Duffy [mailto:mduffy@quarrytech.com]
Sent: Monday, September 24, 2001 3:59 PM
To: Scott Brim; midcom
Subject: Re: [midcom] Latest requirements bullets resolved


At 02:10 PM 9/24/01 -0400, Scott Brim wrote:
>On Mon, Sep 24, 2001 12:56:40PM -0500, Sanjoy Sen allegedly wrote:
>> > You want to know when a ruleset timer expires?  But you're the one who
>> > set it. 
>>
>> The Midcom Agent may not want to maintain the timer state. It may just want
>> to install a timer state in the MB and be notified when the timer expires &
>> react to that notification with specific activities.
>
>This is a months-old argument, about where to put the complexity.
>Recent trends seem to be to pile complexity in the agent and keep the
>middlebox simple -- viz. the example of a simple bump-in-the-wire
>firewall, and the tendency to bundle application proxies with midcom
>agents.  That's evidence of where people seem to want to go.  I also
>think it's a safer base for the future to keep control state complexity
>in the controller, not the controlled object.  That's about fate-sharing
>and "ownership" of state.

I believe that midcom should permit/support transport-layer aware middleboxes.
This involves, for example, the ability for an agent to tell a mb to
install a ruleset for a particular tcp n-tuple that must originate in a
certain direction  and that is to permit packet flow in both directions
from the time the tcp connection is established until it is brought down,
and no more packets thereafter.

This is not a philosophical choice about where to put the complexity.  If a
scenario involves a media flow that does not pass through the agent, the
agent cannot inspect the transport connection state.  Even if the flow
passes through the agent, it is likely that the agent hardware is not
optimized for this type of inspection.  On the other hand, this is exactly
the sort of behaviour that firewalls and NATs are designed for and exhibit
*today*.

i think we have agreed that port numbers are part of the filter spec.  That
to me implies that the middlebox may be "transport layer aware".  I view
that awareness as not limited to static awareness of the transport layer
but also allowing for stateful awareness.

-Mark



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

------_=_NextPart_001_01C145C8.1AB96D20-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 25 10:34: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 ESMTP id KAB05058 for ; Tue, 25 Sep 2001 10:34: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 KAA09662; Tue, 25 Sep 2001 10:30: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 KAA09634 for ; Tue, 25 Sep 2001 10:30:34 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04922 for ; Tue, 25 Sep 2001 10:30:30 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A5095B7C038C; Tue, 25 Sep 2001 10:30:33 -0400 Message-ID: <001f01c145ce$16730220$2300000a@acmepacket.com> From: "Bob Penfield" To: "midcom mail-list" References: <20010925094536.A1268@SBRIM-W2K> Date: Tue, 25 Sep 2001 10:26:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [midcom] accept R3a1 & R3a2 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit In the interest of continued progress, I propose that we accept R3a1 and R3a2. R3a1: The Midcom protocol MUST allow a Midcom agent to communicate with more than one middleboxes simultaneously. R3a2: The Midcom protocol MUST allow a middlebox to communicate with more than one Midcom agent simultaneously. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Scott Brim" To: "midcom mail-list" Sent: Tuesday, September 25, 2001 9:45 AM Subject: [midcom] new bullets text > Bullets -010924.txt is now available at > . > > R1a accepted. > R32 revised and accepted. > R10 deleted in favor of R32. > R13 deleted. > R14 deleted. > R40 deleted in favor of R82. > > Progress is being made. > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 25 11:33:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06634 for ; Tue, 25 Sep 2001 11:33: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 LAA11369; Tue, 25 Sep 2001 11: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 LAA11337 for ; Tue, 25 Sep 2001 11:22:44 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06274 for ; Tue, 25 Sep 2001 11:22:40 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12S6S6; Tue, 25 Sep 2001 11:22:03 -0400 Message-Id: <3.0.5.32.20010925112104.008e33f0@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 25 Sep 2001 11:21:04 -0400 To: "midcom mail-list" From: Mark Duffy Subject: Re: [midcom] accept R3a1 & R3a2 In-Reply-To: <001f01c145ce$16730220$2300000a@acmepacket.com> References: <20010925094536.A1268@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 10:26 AM 9/25/01 -0400, Bob Penfield wrote: >In the interest of continued progress, I propose that we accept R3a1 and >R3a2. > > R3a1: The Midcom protocol MUST allow a Midcom agent to communicate > with more than one middleboxes simultaneously. > > R3a2: The Midcom protocol MUST allow a middlebox to communicate with > more than one Midcom agent simultaneously. Agreed. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 25 11:40:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06823 for ; Tue, 25 Sep 2001 11:40:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12098; Tue, 25 Sep 2001 11:34:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12067 for ; Tue, 25 Sep 2001 11:34:50 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06663 for ; Tue, 25 Sep 2001 11:34:45 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA06240 for ; Tue, 25 Sep 2001 10:34:15 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 25 Sep 2001 10:27:31 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Sep 2001 10:33:52 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E06F18C@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Bob Penfield'" , midcom mail-list Subject: RE: [midcom] accept R3a1 & R3a2 Date: Tue, 25 Sep 2001 10:33:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C145D7.78318140" 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_01C145D7.78318140 Content-Type: text/plain; charset="iso-8859-1" Agreed. > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Tuesday, September 25, 2001 9:27 AM > To: midcom mail-list > Subject: [midcom] accept R3a1 & R3a2 > > > In the interest of continued progress, I propose that we > accept R3a1 and > R3a2. > > R3a1: The Midcom protocol MUST allow a Midcom agent to communicate > with more than one middleboxes simultaneously. > > R3a2: The Midcom protocol MUST allow a middlebox to > communicate with > more than one Midcom agent simultaneously. > > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Scott Brim" > To: "midcom mail-list" > Sent: Tuesday, September 25, 2001 9:45 AM > Subject: [midcom] new bullets text > > > > Bullets -010924.txt is now available at > > . > > > > R1a accepted. > > R32 revised and accepted. > > R10 deleted in favor of R32. > > R13 deleted. > > R14 deleted. > > R40 deleted in favor of R82. > > > > Progress is being made. > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > http://www1.ietf.org/mailman/listinfo/midcom > > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C145D7.78318140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] accept R3a1 & R3a2

Agreed.

> -----Original Message-----
> From: Bob Penfield [mailto:bpenfield@acmepacket.com= ]
> Sent: Tuesday, September 25, 2001 9:27 = AM
> To: midcom mail-list
> Subject: [midcom] accept R3a1 & R3a2
>
>
> In the interest of continued progress, I = propose that we
> accept R3a1 and
> R3a2.
>
>    R3a1: The Midcom protocol = MUST allow a Midcom agent to communicate
>          = with more than one middleboxes simultaneously.
>
>    R3a2: The Midcom protocol = MUST allow a middlebox to
> communicate with
>          = more than one Midcom agent simultaneously.
>
> (-:bob
>
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 130 New Boston Street
> Woburn, MA 01801
> bpenfield@acmepacket.com
>
> ----- Original Message -----
> From: "Scott Brim" = <swb@employees.org>
> To: "midcom mail-list" = <midcom@ietf.org>
> Sent: Tuesday, September 25, 2001 9:45 = AM
> Subject: [midcom] new bullets text
>
>
> > Bullets -010924.txt is now available = at
> > <http://www.employees.org/~swb/midcom.html>.
> >
> > R1a accepted.
> > R32 revised and accepted.
> > R10 deleted in favor of R32.
> > R13 deleted.
> > R14 deleted.
> > R40 deleted in favor of R82.
> >
> > Progress is being made.
> >
> > = _______________________________________________
> > midcom mailing list
> > midcom@ietf.org
> > http://www1.ietf.org/mailman/listinfo/midcom
> >
>
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> http://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C145D7.78318140-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 25 11:42:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06895 for ; Tue, 25 Sep 2001 11:42: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 LAA12006; Tue, 25 Sep 2001 11:33: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 LAA11964 for ; Tue, 25 Sep 2001 11:33:43 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06630 for ; Tue, 25 Sep 2001 11:33:38 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8PFWld18117; Tue, 25 Sep 2001 08:32:47 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-82.cisco.com [10.82.192.82]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACK00608; Tue, 25 Sep 2001 08:32:44 -0700 (PDT) Message-Id: <5.1.0.14.0.20010925113139.00a94e30@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Sep 2001 11:34:42 -0400 To: Mark Duffy , "midcom mail-list" From: Melinda Shore Subject: Re: [midcom] accept R3a1 & R3a2 In-Reply-To: <3.0.5.32.20010925112104.008e33f0@email.quarrytech.com> References: <001f01c145ce$16730220$2300000a@acmepacket.com> <20010925094536.A1268@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 11:21 AM 9/25/01 -0400, Mark Duffy wrote: >> R3a1: The Midcom protocol MUST allow a Midcom agent to communicate >> with more than one middleboxes simultaneously. >> >> R3a2: The Midcom protocol MUST allow a middlebox to communicate with >> more than one Midcom agent simultaneously. > >Agreed. A couple of things: 1) if everybody starts proposing stuff off the list it will work against making progress, and 2) have a good hard think about these and what they actually mean for protocol design. I haven't brought these up yet because I've been trying to get through the obvious stuff and these are decidedly not obvious. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 25 13:02:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09511 for ; Tue, 25 Sep 2001 13:02: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 MAA16169; Tue, 25 Sep 2001 12:59: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 MAA16139 for ; Tue, 25 Sep 2001 12:59:20 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09456 for ; Tue, 25 Sep 2001 12:59:16 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A7E4FA47038C; Tue, 25 Sep 2001 12:59:16 -0400 Message-ID: <004701c145e2$c76205e0$2300000a@acmepacket.com> From: "Bob Penfield" To: "midcom mail-list" , "Melinda Shore" References: <001f01c145ce$16730220$2300000a@acmepacket.com> <20010925094536.A1268@SBRIM-W2K> <5.1.0.14.0.20010925113139.00a94e30@mira-sjc5-4.cisco.com> Subject: Re: [midcom] accept R3a1 & R3a2 Date: Tue, 25 Sep 2001 12:54:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.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'm sorry if I jumped the gun, but at the moment there are only 7 items listed in the "Requirements Under Discussion" section of the bullet list, and I think these are the most obvious. I have been thinking about these particular requirements for several months. I think there has been general agreement on these requirements as they are currently stated. I believe the rewording of these was based on input from many people. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Melinda Shore" To: "Mark Duffy" ; "midcom mail-list" Sent: Tuesday, September 25, 2001 11:34 AM Subject: Re: [midcom] accept R3a1 & R3a2 > At 11:21 AM 9/25/01 -0400, Mark Duffy wrote: > >> R3a1: The Midcom protocol MUST allow a Midcom agent to communicate > >> with more than one middleboxes simultaneously. > >> > >> R3a2: The Midcom protocol MUST allow a middlebox to communicate with > >> more than one Midcom agent simultaneously. > > > >Agreed. > > A couple of things: 1) if everybody starts proposing stuff > off the list it will work against making progress, and 2) > have a good hard think about these and what they actually > mean for protocol design. I haven't brought these up yet > because I've been trying to get through the obvious stuff > and these are decidedly not obvious. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 25 14:10:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10962 for ; Tue, 25 Sep 2001 14:10: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 OAA18169; Tue, 25 Sep 2001 14:07: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 OAA18138 for ; Tue, 25 Sep 2001 14:07:49 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10937 for ; Tue, 25 Sep 2001 14:07:45 -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 f8PI7U307761; Tue, 25 Sep 2001 11:07:30 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-82.cisco.com [10.82.192.82]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACK07126; Tue, 25 Sep 2001 11:06:49 -0700 (PDT) Message-Id: <5.1.0.14.0.20010925135941.00aa4990@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Sep 2001 14:08:46 -0400 To: "Bob Penfield" , "midcom mail-list" From: Melinda Shore Subject: Re: [midcom] accept R3a1 & R3a2 In-Reply-To: <004701c145e2$c76205e0$2300000a@acmepacket.com> References: <001f01c145ce$16730220$2300000a@acmepacket.com> <20010925094536.A1268@SBRIM-W2K> <5.1.0.14.0.20010925113139.00a94e30@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:54 PM 9/25/01 -0400, Bob Penfield wrote: >I'm sorry if I jumped the gun, but at the moment there are only 7 items >listed in the "Requirements Under Discussion" section of the bullet list, >and I think these are the most obvious. I have been thinking about these >particular requirements for several months. I think there has been general >agreement on these requirements as they are currently stated. I believe the >rewording of these was based on input from many people. I think that we need to be clearer about what specific demands this places on the protocol and perhaps include those demands rather than what's currently in there. I think the elements that would be required to do this may actually be in there already. Getting this wrong could potentially lead to a NAT-unfriendly protocol. Really, think about what would be required *of a protocol* for a single agent to talk to multiple middleboxes and see what's currently missing from the current requirements. As stated, R3a1 and R3a2 have virtually no discriminatory value. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Tue Sep 25 22:38:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22813 for ; Tue, 25 Sep 2001 22:38: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 WAA04987; Tue, 25 Sep 2001 22:35: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 WAA04958 for ; Tue, 25 Sep 2001 22:35:34 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22801 for ; Tue, 25 Sep 2001 22:35:29 -0400 (EDT) Received: from MDUFFY ([10.1.1.17]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12S702; Tue, 25 Sep 2001 22:35:02 -0400 Message-Id: <3.0.5.32.20010925223404.007d9520@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 25 Sep 2001 22:34:04 -0400 To: Melinda Shore , "midcom mail-list" From: Mark Duffy Subject: Re: [midcom] accept R3a1 & R3a2 In-Reply-To: <5.1.0.14.0.20010925135941.00aa4990@mira-sjc5-4.cisco.com> References: <004701c145e2$c76205e0$2300000a@acmepacket.com> <001f01c145ce$16730220$2300000a@acmepacket.com> <20010925094536.A1268@SBRIM-W2K> <5.1.0.14.0.20010925113139.00a94e30@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 > >> R3a1: The Midcom protocol MUST allow a Midcom agent to communicate > >> with more than one middleboxes simultaneously. > >> > >> R3a2: The Midcom protocol MUST allow a middlebox to communicate with > >> more than one Midcom agent simultaneously. >I think that we need to be clearer about what specific demands >this places on the protocol and perhaps include those demands >rather than what's currently in there. I think the elements that >would be required to do this may actually be in there already. >Getting this wrong could potentially lead to a NAT-unfriendly >protocol. Really, think about what would be required *of a protocol* >for a single agent to talk to multiple middleboxes and see what's >currently missing from the current requirements. As stated, R3a1 >and R3a2 have virtually no discriminatory value. > >Melinda Melinda, could you elaborate a bit on what dangers you see here? These two seem so fundamental to me that they almost don't need to be stated (but I think they should be). -Mark P.S. both of them might impose some substantive effects on the protocol design if they are construed to include the cases of multiple middleboxes/agents (respectively) residing in the same physical box and having the same IP address. I could see that we might want to clarify them, or add other requirements to clarify, whether multiple logical middleboxes/agents at one IP address need to be supported. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 26 09:16:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17548 for ; Wed, 26 Sep 2001 09:16: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 JAA28275; Wed, 26 Sep 2001 09:12: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 JAA28245 for ; Wed, 26 Sep 2001 09:12:09 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17321 for ; Wed, 26 Sep 2001 09:12:06 -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.6/8.9.1) with ESMTP id f8QDBcG04728; Wed, 26 Sep 2001 06:11:38 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-115.cisco.com [10.82.192.115]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACK32879; Wed, 26 Sep 2001 06:11:35 -0700 (PDT) Message-Id: <5.1.0.14.0.20010926091107.00aaac60@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 26 Sep 2001 09:13:33 -0400 To: Mark Duffy , "midcom mail-list" From: Melinda Shore Subject: Re: [midcom] accept R3a1 & R3a2 In-Reply-To: <3.0.5.32.20010925223404.007d9520@email.quarrytech.com> References: <5.1.0.14.0.20010925135941.00aa4990@mira-sjc5-4.cisco.com> <004701c145e2$c76205e0$2300000a@acmepacket.com> <001f01c145ce$16730220$2300000a@acmepacket.com> <20010925094536.A1268@SBRIM-W2K> <5.1.0.14.0.20010925113139.00a94e30@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 10:34 PM 9/25/01 -0400, Mark Duffy wrote: >Melinda, could you elaborate a bit on what dangers you see here? These two >seem so fundamental to me that they almost don't need to be stated (but I >think they should be). Okay - as stated the "requirements" are too vague and decidedly not useful for protocol selection. The things that need to be done to support the "requirements" are actually the requirements, and I'm not sure that anything needs to be done. My concern is that mishandling this could lead to something we obviously don't want, like protocol-embedded IP addresses. >P.S. both of them might impose some substantive effects on the protocol >design if they are construed to include the cases of multiple >middleboxes/agents (respectively) residing in the same physical box and >having the same IP address. I *really* don't want to see the protocol design being driven by pathological cases. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 26 09:43: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 ESMTP id JAA18891 for ; Wed, 26 Sep 2001 09:43: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 JAA29373; Wed, 26 Sep 2001 09:40: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 JAA29344 for ; Wed, 26 Sep 2001 09:40: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 ESMTP id JAA18833 for ; Wed, 26 Sep 2001 09:40:36 -0400 (EDT) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.11.6/8.9.1) with ESMTP id f8QDe8G20464 for ; Wed, 26 Sep 2001 06:40:08 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-310.cisco.com [10.21.97.54]) by airborne.cisco.com (Mirapoint) with SMTP id AAC29816; Wed, 26 Sep 2001 06:40:06 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Wed, 26 Sep 2001 09:40:05 -0400 Date: Wed, 26 Sep 2001 09:40:05 -0400 From: Scott Brim To: midcom mail-list Subject: Re: [midcom] accept R3a1 & R3a2 Message-ID: <20010926094005.C1584@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom mail-list References: <5.1.0.14.0.20010925135941.00aa4990@mira-sjc5-4.cisco.com> <004701c145e2$c76205e0$2300000a@acmepacket.com> <001f01c145ce$16730220$2300000a@acmepacket.com> <20010925094536.A1268@SBRIM-W2K> <5.1.0.14.0.20010925113139.00a94e30@mira-sjc5-4.cisco.com> <3.0.5.32.20010925223404.007d9520@email.quarrytech.com> <5.1.0.14.0.20010926091107.00aaac60@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20010926091107.00aaac60@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Wed, Sep 26, 2001 at 09:13:33AM -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Wed, Sep 26, 2001 09:13:33AM -0400, Melinda Shore allegedly wrote: > I *really* don't want to see the protocol design being driven by > pathological cases. Would 'must operate through a NAT' be a pathological case? _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 26 10:04:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19478 for ; Wed, 26 Sep 2001 10:04: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 JAA29701; Wed, 26 Sep 2001 09:57: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 JAA29672 for ; Wed, 26 Sep 2001 09:57:04 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19321 for ; Wed, 26 Sep 2001 09:57:01 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12S84R; Wed, 26 Sep 2001 09:56:31 -0400 Message-Id: <3.0.5.32.20010926095534.008bac30@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 26 Sep 2001 09:55:34 -0400 To: Melinda Shore , Mark Duffy , "midcom mail-list" From: Mark Duffy Subject: Re: [midcom] accept R3a1 & R3a2 In-Reply-To: <5.1.0.14.0.20010926091107.00aaac60@mira-sjc5-4.cisco.com> References: <3.0.5.32.20010925223404.007d9520@email.quarrytech.com> <5.1.0.14.0.20010925135941.00aa4990@mira-sjc5-4.cisco.com> <004701c145e2$c76205e0$2300000a@acmepacket.com> <001f01c145ce$16730220$2300000a@acmepacket.com> <20010925094536.A1268@SBRIM-W2K> <5.1.0.14.0.20010925113139.00a94e30@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 09:13 AM 9/26/01 -0400, Melinda Shore wrote: >At 10:34 PM 9/25/01 -0400, Mark Duffy wrote: >>Melinda, could you elaborate a bit on what dangers you see here? These two >>seem so fundamental to me that they almost don't need to be stated (but I >>think they should be). > >Okay - as stated the "requirements" are too vague and decidedly >not useful for protocol selection. The things that need to be >done to support the "requirements" are actually the requirements, I'm not sure what you mean by that. Do you mean that R3a1/2 should be rewritten to state *how* to accomplish what they currently say???? (I suspect not.) These don't seem vague to me either. Do you have a specific rewording to suggest? >and I'm not sure that anything needs to be done. My concern is >that mishandling this could lead to something we obviously don't >want, like protocol-embedded IP addresses. > >>P.S. both of them might impose some substantive effects on the protocol >>design if they are construed to include the cases of multiple >>middleboxes/agents (respectively) residing in the same physical box and >>having the same IP address. > >I *really* don't want to see the protocol design being driven by >pathological cases. > >Melinda Fine by me to explicitly not require support for such cases. Mark _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 26 10:12: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 ESMTP id KAA19692 for ; Wed, 26 Sep 2001 10:12:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00325; Wed, 26 Sep 2001 10:10: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 KAA00292 for ; Wed, 26 Sep 2001 10:10:23 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19666 for ; Wed, 26 Sep 2001 10:10:19 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.11.6/8.9.1) with ESMTP id f8QE9pG10553; Wed, 26 Sep 2001 07:09:51 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-115.cisco.com [10.82.192.115]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACK33725; Wed, 26 Sep 2001 07:09:49 -0700 (PDT) Message-Id: <5.1.0.14.0.20010926100410.00aac600@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 26 Sep 2001 10:11:46 -0400 To: Scott Brim , midcom mail-list From: Melinda Shore Subject: Re: [midcom] accept R3a1 & R3a2 In-Reply-To: <20010926094005.C1584@SBRIM-W2K> References: <5.1.0.14.0.20010926091107.00aaac60@mira-sjc5-4.cisco.com> <5.1.0.14.0.20010925135941.00aa4990@mira-sjc5-4.cisco.com> <004701c145e2$c76205e0$2300000a@acmepacket.com> <001f01c145ce$16730220$2300000a@acmepacket.com> <20010925094536.A1268@SBRIM-W2K> <5.1.0.14.0.20010925113139.00a94e30@mira-sjc5-4.cisco.com> <3.0.5.32.20010925223404.007d9520@email.quarrytech.com> <5.1.0.14.0.20010926091107.00aaac60@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 09:40 AM 9/26/01 -0400, Scott Brim wrote: >Would 'must operate through a NAT' be a pathological case? The presence of more than one NAT is not that uncommon, unfortunately. I've personally never heard of multiple middleboxes sharing a single address, other than failover scenarios or clustering, where routing is handled at a lower layer. Are there such things? As I said, it is not my impression that much thought has been given to what this requirement actually means for protocol design. I think we're covered. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 26 10:35: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 ESMTP id KAA20160 for ; Wed, 26 Sep 2001 10:35: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 KAA01180; Wed, 26 Sep 2001 10:32: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 KAA01148 for ; Wed, 26 Sep 2001 10:32:49 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20115 for ; Wed, 26 Sep 2001 10:32:45 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A70CD58E038C; Wed, 26 Sep 2001 10:32:44 -0400 Message-ID: <018001c14697$da4d7580$2300000a@acmepacket.com> From: "Bob Penfield" To: "Mark Duffy" , "midcom mail-list" , "Melinda Shore" References: <5.1.0.14.0.20010925135941.00aa4990@mira-sjc5-4.cisco.com> <004701c145e2$c76205e0$2300000a@acmepacket.com> <001f01c145ce$16730220$2300000a@acmepacket.com> <20010925094536.A1268@SBRIM-W2K> <5.1.0.14.0.20010925113139.00a94e30@mira-sjc5-4.cisco.com> <5.1.0.14.0.20010926091107.00aaac60@mira-sjc5-4.cisco.com> Subject: Re: [midcom] accept R3a1 & R3a2 Date: Wed, 26 Sep 2001 10:30: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 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: "Mark Duffy" ; "midcom mail-list" Sent: Wednesday, September 26, 2001 9:13 AM Subject: Re: [midcom] accept R3a1 & R3a2 > At 10:34 PM 9/25/01 -0400, Mark Duffy wrote: > >Melinda, could you elaborate a bit on what dangers you see here? These two > >seem so fundamental to me that they almost don't need to be stated (but I > >think they should be). > > Okay - as stated the "requirements" are too vague and decidedly > not useful for protocol selection. The things that need to be > done to support the "requirements" are actually the requirements, > and I'm not sure that anything needs to be done. My concern is > that mishandling this could lead to something we obviously don't > want, like protocol-embedded IP addresses. > By protocol-embeddded IP addresses, I assume that you are talking about the addresses of the agent and the middlebox. Maybe we need to explicity state that we don't want those addresses embedded in the protocol. Given that the whole idea of midcom arose because so many application protocols have embedded addresses, relying on protocol-embedded addresses of the agent & the middlebox in the midcom protocol would be the last thing we would do. I like Mark see the ability of a midcom agent having midcom sessions with multiple middleboxes and multiple midcom agents having midcom sessions with one middlebox as fundamental. I think these requirements are here so that we don't pick a solution that allows for only a single midcom agent talking to a single middlebox. > >P.S. both of them might impose some substantive effects on the protocol > >design if they are construed to include the cases of multiple > >middleboxes/agents (respectively) residing in the same physical box and > >having the same IP address. > > I *really* don't want to see the protocol design being driven by > pathological cases. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 26 10:46:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20386 for ; Wed, 26 Sep 2001 10:46: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 KAA01405; Wed, 26 Sep 2001 10:43: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 KAA01372 for ; Wed, 26 Sep 2001 10:43:16 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20326 for ; Wed, 26 Sep 2001 10:43:13 -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 f8QEegI18823; Wed, 26 Sep 2001 07:40:43 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-115.cisco.com [10.82.192.115]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACK34405; Wed, 26 Sep 2001 07:42:39 -0700 (PDT) Message-Id: <5.1.0.14.0.20010926104003.00ab7ec0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 26 Sep 2001 10:44:36 -0400 To: "Bob Penfield" , "midcom mail-list" From: Melinda Shore Subject: Re: [midcom] accept R3a1 & R3a2 In-Reply-To: <018001c14697$da4d7580$2300000a@acmepacket.com> References: <5.1.0.14.0.20010925135941.00aa4990@mira-sjc5-4.cisco.com> <004701c145e2$c76205e0$2300000a@acmepacket.com> <001f01c145ce$16730220$2300000a@acmepacket.com> <20010925094536.A1268@SBRIM-W2K> <5.1.0.14.0.20010925113139.00a94e30@mira-sjc5-4.cisco.com> <5.1.0.14.0.20010926091107.00aaac60@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 10:30 AM 9/26/01 -0400, Bob Penfield wrote: >I like Mark see the ability of a midcom agent having midcom sessions with >multiple middleboxes and multiple midcom agents having midcom sessions with >one middlebox as fundamental. I think these requirements are here so that we >don't pick a solution that allows for only a single midcom agent talking to >a single middlebox. Okay, there does seem to be consensus on this. I do think that these are not useful requirements as stated, I do think that we're already covered on this, and I've received guidance from an AD that these requirements don't impart thrill, but I have no doubt that someone will step forward to defend this decision when it gets tossed back at us by the IESG. Let's accept them. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 26 10:58:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20509 for ; Wed, 26 Sep 2001 10:58: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 KAA01724; Wed, 26 Sep 2001 10:56: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 KAA01693 for ; Wed, 26 Sep 2001 10:56: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 KAA20495 for ; Wed, 26 Sep 2001 10:56:25 -0400 (EDT) Message-ID: <20010926145626.48499.qmail@web13807.mail.yahoo.com> Received: from [65.12.33.187] by web13807.mail.yahoo.com via HTTP; Wed, 26 Sep 2001 07:56:26 PDT Date: Wed, 26 Sep 2001 07:56:26 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] accept R3a1 & R3a2 To: midcom mail-list In-Reply-To: <5.1.0.14.0.20010926091107.00aaac60@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 --- Melinda Shore wrote: > At 10:34 PM 9/25/01 -0400, Mark Duffy wrote: > >Melinda, could you elaborate a bit on what dangers you see here? These two > >seem so fundamental to me that they almost don't need to be stated (but I > >think they should be). > > Okay - as stated the "requirements" are too vague and decidedly > not useful for protocol selection. The things that need to be > done to support the "requirements" are actually the requirements, > and I'm not sure that anything needs to be done. My concern is > that mishandling this could lead to something we obviously don't > want, like protocol-embedded IP addresses. > I dont understand your concern about "protocol-embedded IP address". The MIDCOM sessions are bound to have IP addresses embedded for control/signaling/query purposes. Why do we not want that? Secondly, how is this concern related to R3a1 & R3a2? As ohers pointed out, R3a1 and R3a2 seem rather straight forward and obvious requirements to me. regards, suresh ===== __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 26 10:58:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20524 for ; Wed, 26 Sep 2001 10:58: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 KAA01785; Wed, 26 Sep 2001 10:57: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 KAA01751 for ; Wed, 26 Sep 2001 10:57:12 -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 ESMTP id KAA20504 for ; Wed, 26 Sep 2001 10:57: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 KAA25262; Wed, 26 Sep 2001 10:56:55 -0400 (EDT) Message-Id: <200109261456.KAA25262@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bob Penfield" cc: "Mark Duffy" , "midcom mail-list" , "Melinda Shore" Subject: Re: [midcom] accept R3a1 & R3a2 In-reply-to: Your message of "Wed, 26 Sep 2001 10:30:55 EDT." <018001c14697$da4d7580$2300000a@acmepacket.com> Date: Wed, 26 Sep 2001 10:56:55 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > Given that the > whole idea of midcom arose because so many application protocols have > embedded addresses no, the whole idea of midcom was a desperate attempt to make a few more applications work through NATs. but NATs cause problems for a great many more applications than those that have embedded addresses. Keith _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 26 11:29: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 ESMTP id LAA21115 for ; Wed, 26 Sep 2001 11:29: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 LAA02340; Wed, 26 Sep 2001 11:11: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 LAA02307 for ; Wed, 26 Sep 2001 11:11:26 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20751 for ; Wed, 26 Sep 2001 11:11:23 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A01DFA82038C; Wed, 26 Sep 2001 11:11:25 -0400 Message-ID: <01de01c1469d$42033200$2300000a@acmepacket.com> From: "Bob Penfield" To: "midcom mail-list" Date: Wed, 26 Sep 2001 11:09: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 Subject: [midcom] resource/ruleset ownership (R3b, R59 & R79) Sender: 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 some questions/comments on these items relative to ownership. R3b: The Midcom protocol MUST support multiple agents manipulating the same middlebox resource. R59: The MIDCOM Protocol must allow the ownership of a requested flow to be transferred from one MIDCOM Agent to another. R79: The midcom protocol must not preclude multiple authorized agents from working on the same ruleset. First, R3b and R79 seem to be talking about the same thing. My question is: based on our current definition of ruleset, what other resources would a midcom agent manipulate? If rulesets (and their component parts) are the only thing that an agent is allowed to manipulate, then we should pick either R3b (s/resource/ruleset/) or R79. Given that we want to allow (or at least not preclude) multiple agents manipulating the same ruleset (e.g. one agent creates it and another deletes it), the issue is how does the middlebox decide that a given agent is authorized to manipulate a given ruleset? I do not like R59 because it requires that the application (via the midcom agent) explicitly handoff the "ownership" to another. This is particularly problematic when you have redundancy in the application. If a given instance of the application (and its midcom agent that created the ruleset) dies, the midcom agent associated with a redundant instance of the application needs to be able to delete the ruleset when the application determines that the ruleset is no longer required (e.g. when a SIP session ends, the ruleset allowing the RTP flows needs to be removed). So, do we have a notion of multiple ownership which is expressed in the protocol? Or does the middlebox have policy (locally or acquired from a policy server) that somehow defines the flavors of rulesets that each agent is allowed to manipulate? Or is there another approach? What I mean by "flavors" is that the policy might express the ranges of addresses and ports that a given set of agents were allowed to define firewall pin-holes for. Or in the case of NAT, it would be the pool of addresses and ports that could be given out for NAT bindings. I think I prefer the policy approach because it removes the issue of midcom agents knowing about each other from the midcom protocol. In that case, do we need to address this as part of the policy server component of the framework? (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 26 11:33: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 ESMTP id LAA21251 for ; Wed, 26 Sep 2001 11:33: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 LAA02224; Wed, 26 Sep 2001 11:04: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 LAA02191 for ; Wed, 26 Sep 2001 11:04: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 ESMTP id LAA20649 for ; Wed, 26 Sep 2001 11:04:31 -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 f8QF4Fd21629; Wed, 26 Sep 2001 08:04:15 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-115.cisco.com [10.82.192.115]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACK34858; Wed, 26 Sep 2001 08:04:00 -0700 (PDT) Message-Id: <5.1.0.14.0.20010926110125.00ab4cd0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 26 Sep 2001 11:05:56 -0400 To: Pyda Srisuresh , midcom mail-list From: Melinda Shore Subject: Re: [midcom] accept R3a1 & R3a2 In-Reply-To: <20010926145626.48499.qmail@web13807.mail.yahoo.com> References: <5.1.0.14.0.20010926091107.00aaac60@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:56 AM 9/26/01 -0700, Pyda Srisuresh wrote: >I dont understand your concern about "protocol-embedded IP address". >The MIDCOM sessions are bound to have IP addresses embedded for >control/signaling/query purposes. Why do we not want that? Transporting an address to be installed as a NAT table mapping is not the same as using what should be a transport address to demultiplex endpoints. >Secondly, how is this concern related to R3a1 & R3a2? >As ohers pointed out, R3a1 and R3a2 seem rather straight >forward and obvious requirements to me. We're in motherhood and apple pie-land here. Additionally, these requirements as stated do not help distinguish among candidate protocols, and there are other mechanisms already in there (like transport addresses, which are implicit in any network communication, along with transaction or resource identifiers). These are two very, very low-quality requirements. Nevertheless, we have consensus. Let's move on. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 26 11:39:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21375 for ; Wed, 26 Sep 2001 11:39: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 LAA02512; Wed, 26 Sep 2001 11: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 LAA02481 for ; Wed, 26 Sep 2001 11:21:20 -0400 (EDT) Received: from WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com ([131.107.3.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20917 for ; Wed, 26 Sep 2001 11:21:17 -0400 (EDT) Received: from win-hub-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.229]) by WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Wed, 26 Sep 2001 08:19:09 -0700 Received: from 157.54.5.226 by win-hub-01.wingroup.windeploy.ntdev.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 26 Sep 2001 08:19:09 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by win-hub-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Wed, 26 Sep 2001 08:19:09 -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.3651); Wed, 26 Sep 2001 08:18:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] accept R3a1 & R3a2 Date: Wed, 26 Sep 2001 08:18:31 -0700 Message-ID: Thread-Topic: [midcom] accept R3a1 & R3a2 Thread-Index: AcFGmNCj+8Z3TOpBSui8/VxRgZ3migABQvEQ From: "Christian Huitema" To: "Melinda Shore" , "Scott Brim" , "midcom mail-list" X-OriginalArrivalTime: 26 Sep 2001 15:18:31.0426 (UTC) FILETIME=[804AFE20:01C1469E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA02482 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, September 26, 2001 7:12 AM > To: Scott Brim; midcom mail-list > Subject: Re: [midcom] accept R3a1 & R3a2 > > > At 09:40 AM 9/26/01 -0400, Scott Brim wrote: > >Would 'must operate through a NAT' be a pathological case? > > The presence of more than one NAT is not that uncommon, > unfortunately. I've personally never heard of multiple > middleboxes sharing a single address, other than failover > scenarios or clustering, where routing is handled at a > lower layer. Are there such things? As I said, it is not > my impression that much thought has been given to what > this requirement actually means for protocol design. I > think we're covered. If there is a requirement, it is that the Midcom client can establish a connection to the server securely, even if there are one or several middlemunglers between the client and that specific server. However, we should be clear that the client is expected to describe packets exactly as they are seen by the controlled middlebox, and that we are certainly not supporting, let alone requiring, that the intermediates rewrite the MIDCOM packets. In practical deployment cases, I expect the communication between client and server to be encrypted. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 26 12:07: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 ESMTP id MAA21987 for ; Wed, 26 Sep 2001 12:07: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 MAA04895; Wed, 26 Sep 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 MAA04860 for ; Wed, 26 Sep 2001 12:03: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 ESMTP id MAA21841 for ; Wed, 26 Sep 2001 12:02:57 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8QG2Vv10767; Wed, 26 Sep 2001 09:02:31 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-115.cisco.com [10.82.192.115]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACL00341; Wed, 26 Sep 2001 09:02:21 -0700 (PDT) Message-Id: <5.1.0.14.0.20010926120335.00a5fb30@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 26 Sep 2001 12:04:14 -0400 To: "Bob Penfield" , "midcom mail-list" From: Melinda Shore Subject: Re: [midcom] resource/ruleset ownership (R3b, R59 & R79) In-Reply-To: <01de01c1469d$42033200$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 11:09 AM 9/26/01 -0400, Bob Penfield wrote: >Given that we want to allow (or at least not preclude) multiple agents >manipulating the same ruleset That decision hasn't been made by the group yet. There was substantial disagreement in London. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 26 12:18: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 ESMTP id MAA22413 for ; Wed, 26 Sep 2001 12:18:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05716; Wed, 26 Sep 2001 12:16: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 MAA05678 for ; Wed, 26 Sep 2001 12:16:28 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22353 for ; Wed, 26 Sep 2001 12:16:25 -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 f8QGFxv21479 for ; Wed, 26 Sep 2001 09:15:59 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-310.cisco.com [10.21.97.54]) by airborne.cisco.com (Mirapoint) with SMTP id AAC31683; Wed, 26 Sep 2001 09:15:56 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Wed, 26 Sep 2001 12:15:54 -0400 Date: Wed, 26 Sep 2001 12:15:54 -0400 From: Scott Brim To: midcom mail-list Subject: Re: [midcom] resource/ruleset ownership (R3b, R59 & R79) Message-ID: <20010926121554.E1584@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom mail-list References: <01de01c1469d$42033200$2300000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01de01c1469d$42033200$2300000a@acmepacket.com>; from bpenfield@acmepacket.com on Wed, Sep 26, 2001 at 11:09:37AM -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Wed, Sep 26, 2001 11:09:37AM -0400, Bob Penfield allegedly wrote: > I have some questions/comments on these items relative to ownership. > > R3b: The Midcom protocol MUST support multiple agents manipulating > the same middlebox resource. > > R59: The MIDCOM Protocol must allow the ownership of a requested flow > to be transferred from one MIDCOM Agent to another. > > R79: The midcom protocol must not preclude multiple authorized agents > from working on the same ruleset. > > First, R3b and R79 seem to be talking about the same thing. My question is: > based on our current definition of ruleset, what other resources would a > midcom agent manipulate? If rulesets (and their component parts) are the > only thing that an agent is allowed to manipulate, then we should pick > either R3b (s/resource/ruleset/) or R79. OK. "Resource" means more than rulesets, but I believe you're right that the only thing an agent gets to influence *directly* is rulesets. > Given that we want to allow (or at least not preclude) multiple agents > manipulating the same ruleset (e.g. one agent creates it and another deletes > it), the issue is how does the middlebox decide that a given agent is > authorized to manipulate a given ruleset? First, it's not given (yet -- that's the point of your mail, yes?). Second, part of initial handshaking is authentication/authorization for the middlebox/agent functions as wholes, and then there may be further authorization checking for each transaction (with or without involvement of a policy server). > I do not like R59 because it requires that the application (via the midcom > agent) explicitly handoff the "ownership" to another. This is particularly > problematic when you have redundancy in the application. If a given instance > of the application (and its midcom agent that created the ruleset) dies, the > midcom agent associated with a redundant instance of the application needs > to be able to delete the ruleset when the application determines that the > ruleset is no longer required (e.g. when a SIP session ends, the ruleset > allowing the RTP flows needs to be removed). I thought we already tossed out ownership in discussions in and around the last IETF. > So, do we have a notion of multiple ownership which is expressed in the > protocol? Or does the middlebox have policy (locally or acquired from a > policy server) that somehow defines the flavors of rulesets that each agent > is allowed to manipulate? Or is there another approach? Those are separate questions, not mutually-exclusive alternatives. Personally I think (1) no, (2) yes, (3) yes but not a desirable one. > What I mean by "flavors" is that the policy might express the ranges of > addresses and ports that a given set of agents were allowed to define > firewall pin-holes for. Or in the case of NAT, it would be the pool of > addresses and ports that could be given out for NAT bindings. Yes. > I think I prefer the policy approach because it removes the issue of midcom > agents knowing about each other from the midcom protocol. In that case, do > we need to address this as part of the policy server component of the > framework? Yes. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 26 12:19:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22438 for ; Wed, 26 Sep 2001 12:19: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 MAA05328; Wed, 26 Sep 2001 12:10: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 MAA05298 for ; Wed, 26 Sep 2001 12:10:54 -0400 (EDT) Received: from WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com ([131.107.3.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22169 for ; Wed, 26 Sep 2001 12:10:50 -0400 (EDT) Received: from win-hub-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.229]) by WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Wed, 26 Sep 2001 09:10:14 -0700 Received: from 157.54.5.226 by win-hub-01.wingroup.windeploy.ntdev.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 26 Sep 2001 09:10:14 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-hub-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Wed, 26 Sep 2001 09:10:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] resource/ruleset ownership (R3b, R59 & R79) Date: Wed, 26 Sep 2001 09:10:14 -0700 Message-ID: Thread-Topic: [midcom] resource/ruleset ownership (R3b, R59 & R79) Thread-Index: AcFGoJojB6PNACNTRIC78NY0iGju+AAAi4Ww From: "Christian Huitema" To: "Bob Penfield" , "midcom mail-list" X-OriginalArrivalTime: 26 Sep 2001 16:10:14.0578 (UTC) FILETIME=[B9EA6920:01C146A5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA05299 Sender: 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: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Wednesday, September 26, 2001 8:10 AM > To: midcom mail-list > Subject: [midcom] resource/ruleset ownership (R3b, R59 & R79) > > > I have some questions/comments on these items relative to ownership. > > R3b: The Midcom protocol MUST support multiple agents manipulating > the same middlebox resource. > > R59: The MIDCOM Protocol must allow the ownership of a requested flow > to be transferred from one MIDCOM Agent to another. > > R79: The midcom protocol must not preclude multiple authorized agents > from working on the same ruleset. > > First, R3b and R79 seem to be talking about the same thing. > My question is: > based on our current definition of ruleset, what other > resources would a > midcom agent manipulate? If rulesets (and their component > parts) are the > only thing that an agent is allowed to manipulate, then we should pick > either R3b (s/resource/ruleset/) or R79. > > Given that we want to allow (or at least not preclude) multiple agents > manipulating the same ruleset (e.g. one agent creates it and > another deletes > it), the issue is how does the middlebox decide that a given agent is > authorized to manipulate a given ruleset? > > I do not like R59 because it requires that the application > (via the midcom > agent) explicitly handoff the "ownership" to another. This is > particularly > problematic when you have redundancy in the application. If a > given instance > of the application (and its midcom agent that created the > ruleset) dies, the > midcom agent associated with a redundant instance of the > application needs > to be able to delete the ruleset when the application > determines that the > ruleset is no longer required (e.g. when a SIP session ends, > the ruleset > allowing the RTP flows needs to be removed). You are correct. We should scratch R59, and in fact scratch any reference to "ownership of flows." In fact, we could just keep a slightly more explicit version of R79: R79: The midcom protocol must not preclude multiple authorized agents from working on the same ruleset, subject to access control rules defined by the administrator of the middlebox. A possible implementation is to have a ruleset access control similar to file access control, with creators, groups, superusers and the like. There is no need for the wording in R59 about ownership of flows. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 26 12:48: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 ESMTP id MAA23207 for ; Wed, 26 Sep 2001 12:48: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 MAA07066; Wed, 26 Sep 2001 12:39: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 MAA07039 for ; Wed, 26 Sep 2001 12:39:05 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23034 for ; Wed, 26 Sep 2001 12:39:04 -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 f8QGcav09638; Wed, 26 Sep 2001 09:38:36 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-115.cisco.com [10.82.192.115]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ACL01543; Wed, 26 Sep 2001 09:38:32 -0700 (PDT) Message-Id: <5.1.0.14.0.20010926123940.00a4b330@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 26 Sep 2001 12:40:25 -0400 To: "Bob Penfield" , "midcom mail-list" From: Melinda Shore Subject: Re: [midcom] resource/ruleset ownership (R3b, R59 & R79) In-Reply-To: <003701c146a8$4b48d940$2300000a@acmepacket.com> References: <5.1.0.14.0.20010926120335.00a5fb30@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 12:28 PM 9/26/01 -0400, Bob Penfield wrote: > R79: The midcom protocol must not preclude multiple authorized agents > from working on the same ruleset. > > This was accepted at the London meeting, except that we need > to decide on the very last word. > >There was substantial disagreement on the "ownership" issue, however I think >there is a widespread belief that midcom will need to work in an environment >where there is redundancy in the application that would lead to the need for >multiple midcom agents to access the same ruleset/resource. You'll note that R79 doesn't discuss ownership as such. I think that it's sufficient to deal with this as an authorization question. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 26 12:48:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23237 for ; Wed, 26 Sep 2001 12:48: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 MAA06508; Wed, 26 Sep 2001 12:30:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06472 for ; Wed, 26 Sep 2001 12:30:29 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22807 for ; Wed, 26 Sep 2001 12:30:26 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A2A21D54038C; Wed, 26 Sep 2001 12:30:26 -0400 Message-ID: <003701c146a8$4b48d940$2300000a@acmepacket.com> From: "Bob Penfield" To: "midcom mail-list" , "Melinda Shore" References: <5.1.0.14.0.20010926120335.00a5fb30@mira-sjc5-4.cisco.com> Subject: Re: [midcom] resource/ruleset ownership (R3b, R59 & R79) Date: Wed, 26 Sep 2001 12:28:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.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 > >Given that we want to allow (or at least not preclude) multiple agents > >manipulating the same ruleset > > That decision hasn't been made by the group yet. There > was substantial disagreement in London. > Please excuse me, s/Given that/If/ However, according to the 9/24/01 bullet list: R79: The midcom protocol must not preclude multiple authorized agents from working on the same ruleset. This was accepted at the London meeting, except that we need to decide on the very last word. There was substantial disagreement on the "ownership" issue, however I think there is a widespread belief that midcom will need to work in an environment where there is redundancy in the application that would lead to the need for multiple midcom agents to access the same ruleset/resource. (-:bob _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 26 13:09:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23744 for ; Wed, 26 Sep 2001 13:09: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 NAA08106; Wed, 26 Sep 2001 13:07: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 NAA08077 for ; Wed, 26 Sep 2001 13:07:46 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23699 for ; Wed, 26 Sep 2001 13:07:45 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AB5A1E2D038C; Wed, 26 Sep 2001 13:07:38 -0400 Message-ID: <001301c146ad$7da16420$2300000a@acmepacket.com> From: "Bob Penfield" To: "midcom mail-list" , "Melinda Shore" References: <5.1.0.14.0.20010926120335.00a5fb30@mira-sjc5-4.cisco.com> <5.1.0.14.0.20010926123940.00a4b330@mira-sjc5-4.cisco.com> Subject: Re: [midcom] resource/ruleset ownership (R3b, R59 & R79) Date: Wed, 26 Sep 2001 13:05:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Melinda Shore" To: "Bob Penfield" ; "midcom mail-list" Sent: Wednesday, September 26, 2001 12:40 PM Subject: Re: [midcom] resource/ruleset ownership (R3b, R59 & R79) > At 12:28 PM 9/26/01 -0400, Bob Penfield wrote: > > R79: The midcom protocol must not preclude multiple authorized agents > > from working on the same ruleset. > > > > This was accepted at the London meeting, except that we need > > to decide on the very last word. > > > >There was substantial disagreement on the "ownership" issue, however I think > >there is a widespread belief that midcom will need to work in an environment > >where there is redundancy in the application that would lead to the need for > >multiple midcom agents to access the same ruleset/resource. > > You'll note that R79 doesn't discuss ownership as such. I think > that it's sufficient to deal with this as an authorization question. > Absolutely. I'm in favor of rejecting R59 and "ownership" and using the policy approach to control which midcom agents can access which rulesets. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 26 21: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 ESMTP id VAA01949 for ; Wed, 26 Sep 2001 21:13:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA21481; Wed, 26 Sep 2001 21:11: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 VAA21454 for ; Wed, 26 Sep 2001 21:11:27 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01925 for ; Wed, 26 Sep 2001 21:11:24 -0400 (EDT) Received: from asimu-u5.cisco.com (asimu-u5.cisco.com [128.107.162.97]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8R1Auv07210; Wed, 26 Sep 2001 18:10:56 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by asimu-u5.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA07340; Wed, 26 Sep 2001 18:10:55 -0700 (PDT) Message-ID: <3BB27C9E.D8F40A63@cisco.com> Date: Wed, 26 Sep 2001 18:10:54 -0700 From: Adina Simu Organization: Cisco Systems X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: midcom mail-list CC: Christian Huitema , Melinda Shore , Scott Brim Subject: Re: [midcom] accept R3a1 & R3a2 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 Christian Huitema wrote: > > > From: Melinda Shore [mailto:mshore@cisco.com] > > Sent: Wednesday, September 26, 2001 7:12 AM > > To: Scott Brim; midcom mail-list > > Subject: Re: [midcom] accept R3a1 & R3a2 > > > > > > At 09:40 AM 9/26/01 -0400, Scott Brim wrote: > > >Would 'must operate through a NAT' be a pathological case? > > > > The presence of more than one NAT is not that uncommon, > > unfortunately. I've personally never heard of multiple > > middleboxes sharing a single address, other than failover > > scenarios or clustering, where routing is handled at a > > lower layer. Are there such things? As I said, it is not > > my impression that much thought has been given to what > > this requirement actually means for protocol design. I > > think we're covered. > > If there is a requirement, it is that the Midcom client can establish a > connection to the server securely, even if there are one or several > middlemunglers between the client and that specific server. However, we > should be clear that the client is expected to describe packets exactly > as they are seen by the controlled middlebox, and that we are certainly > not supporting, let alone requiring, that the intermediates rewrite the > MIDCOM packets. In practical deployment cases, I expect the > communication between client and server to be encrypted. A far-fetched scenario: agent----NAT1---FW1--NAT2----FW2-----... If the agent has to control all these, how does it know the correct order in which they should be contacted? -Adina > > -- Christian Huitema > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom -- Adina Simu Software Engineer Core IP Eng - Services & Security IOS Technologies Division Phone: 408-525-1383 _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Wed Sep 26 21:59:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03305 for ; Wed, 26 Sep 2001 21:59:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22233; Wed, 26 Sep 2001 21:41: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 VAA22204 for ; Wed, 26 Sep 2001 21:41:28 -0400 (EDT) Received: from WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com ([131.107.3.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03149 for ; Wed, 26 Sep 2001 21:41:25 -0400 (EDT) Received: from win-hub-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.229]) by WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Wed, 26 Sep 2001 18:33:24 -0700 Received: from 157.54.5.226 by win-hub-01.wingroup.windeploy.ntdev.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 26 Sep 2001 18:33:24 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-hub-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Wed, 26 Sep 2001 18:33:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] accept R3a1 & R3a2 Date: Wed, 26 Sep 2001 18:33:24 -0700 Message-ID: Thread-Topic: [midcom] accept R3a1 & R3a2 Thread-Index: AcFG8UCuEwthmEn0RCmUqglV3CCS2QAAx4Zg From: "Christian Huitema" To: "Adina Simu" , "midcom mail-list" Cc: "Melinda Shore" , "Scott Brim" X-OriginalArrivalTime: 27 Sep 2001 01:33:24.0811 (UTC) FILETIME=[6676C9B0:01C146F4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA22205 Sender: 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 > > If there is a requirement, it is that the Midcom client can > establish a > > connection to the server securely, even if there are one or several > > middlemunglers between the client and that specific server. However, > we > > should be clear that the client is expected to describe packets > exactly > > as they are seen by the controlled middlebox, and that we are > certainly > > not supporting, let alone requiring, that the intermediates rewrite > the > > MIDCOM packets. In practical deployment cases, I expect the > > communication between client and server to be encrypted. > > A far-fetched scenario: > > agent----NAT1---FW1--NAT2----FW2-----... > > If the agent has to control all these, how does it know the correct > order in which they should be contacted? This is a discovery issue. Discovery is out of scope. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 27 13:01:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07045 for ; Thu, 27 Sep 2001 13:01: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 MAA27310; Thu, 27 Sep 2001 12:57: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 MAA27282 for ; Thu, 27 Sep 2001 12:57:21 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06832 for ; Thu, 27 Sep 2001 12:57:21 -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.6/8.9.1) with ESMTP id f8RGurG29120 for ; Thu, 27 Sep 2001 09:56:53 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-92.cisco.com [10.82.192.92]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAA28242; Thu, 27 Sep 2001 09:56:42 -0700 (PDT) Message-Id: <5.1.0.14.0.20010927125732.00a5c260@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 Sep 2001 12:58:49 -0400 To: midcom mail-list From: Melinda Shore Subject: Re: [midcom] resource/ruleset ownership (R3b, R59 & R79) In-Reply-To: <20010926121554.E1584@SBRIM-W2K> References: <01de01c1469d$42033200$2300000a@acmepacket.com> <01de01c1469d$42033200$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 The proposal before us is to delete R3b and R59 in favor of retaining R79. There doesn't seem to be any objection so far, although this was a hotly contested topic in London. If there are objections to this proposal, please speak up. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 27 15:47:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11888 for ; Thu, 27 Sep 2001 15:47: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 PAA01309; Thu, 27 Sep 2001 15:42: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 PAA01278 for ; Thu, 27 Sep 2001 15:42:32 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11783 for ; Thu, 27 Sep 2001 15:42: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 f8RJgFd27175 for ; Thu, 27 Sep 2001 12:42:15 -0700 (PDT) Received: from spandex.cisco.com (rtp-vpn-92.cisco.com [10.82.192.92]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AAB05164; Thu, 27 Sep 2001 12:41:50 -0700 (PDT) Message-Id: <5.1.0.14.0.20010927153421.00a6b1f0@mira-sjc5-4.cisco.com> X-Sender: mshore@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 Sep 2001 15:43:54 -0400 To: midcom From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] More bullets Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org R15: A Midcom agent ought to be able to have a single MIDCOM connection with a middlebox and use the MIDCOM interface on the middlebox to interface with different middlebox functions on the same middlebox interface. I'd like to drop the trailing "interface" on this one and propose keeping this. R44: The protocol MUST permit the expression of direction to be associated with a pin-hole. The direction MUST be specified in terms that apply to external view of the Middlebox. This directionality shall be expressed as 'in', 'out' or 'loopback' (meaning both 'in' and 'out' of the same side of the same Middlebox realm). The proposal is to drop this: we've already accepted R82, which gives broad leeway in descriptions of filtering rules. R74: A Midcom Agent MUST be able to discover what resources are available on a middlebox. Proposal: drop. We've already discussed meaningful error messages. R68: The Midcom Protocol MUST allow for preservation of the control messages once the association has been established. Proposal: drop. Once we get these settled we'll tackle semantics. Melinda _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 27 16: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 ESMTP id QAA12517 for ; Thu, 27 Sep 2001 16:21: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 QAA02389; Thu, 27 Sep 2001 16:18: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 QAA02361 for ; Thu, 27 Sep 2001 16:18:54 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12483 for ; Thu, 27 Sep 2001 16:18:52 -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 f8RKIOv19604 for ; Thu, 27 Sep 2001 13:18:24 -0700 (PDT) Received: from SBRIM-W2K (rtp-vpn1-277.cisco.com [10.82.225.21]) by airborne.cisco.com (Mirapoint) with SMTP id AAC53406; Thu, 27 Sep 2001 13:18:20 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 27 Sep 2001 16:18:18 -0400 Date: Thu, 27 Sep 2001 16:18:18 -0400 From: Scott Brim To: midcom Subject: Re: [midcom] More bullets Message-ID: <20010927161818.E736@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom References: <5.1.0.14.0.20010927153421.00a6b1f0@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20010927153421.00a6b1f0@mira-sjc5-4.cisco.com>; from mshore@cisco.com on Thu, Sep 27, 2001 at 03:43:54PM -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Thu, Sep 27, 2001 03:43:54PM -0400, Melinda Shore allegedly wrote: > R15: A Midcom agent ought to be able to have a single MIDCOM > connection with a middlebox and use the MIDCOM interface on the > middlebox to interface with different middlebox functions on the > same middlebox interface. > > I'd like to drop the trailing "interface" on this one and propose > keeping this. What other functions would an agent use the midcom protocol for, besides the one (managing rulesets) which we've already covered in other requirements? Why would the midcom protocol be a better way to get at those functions than some other existing protocol? I think it's better to drop this entirely until we know specifically what the need is. Whatever the midcom protocol ends up doing, it will be exactly what needs to be done and no more. I'd leave this up to the next WG. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 27 16:57:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13447 for ; Thu, 27 Sep 2001 16:57: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 QAA03574; Thu, 27 Sep 2001 16:42: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 QAA03546 for ; Thu, 27 Sep 2001 16:42:53 -0400 (EDT) Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13156 for ; Thu, 27 Sep 2001 16:42:49 -0400 (EDT) Received: from 157.54.9.104 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 27 Sep 2001 13:42:18 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 27 Sep 2001 13:42:16 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 27 Sep 2001 13:42:15 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 27 Sep 2001 13:41:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] More bullets Date: Thu, 27 Sep 2001 13:41:20 -0700 Message-ID: Thread-Topic: [midcom] More bullets Thread-Index: AcFHkqzN5sZAf/SCSYCp6+T+VK8CSwAAfhvA From: "Christian Huitema" To: "Scott Brim" , "midcom" X-OriginalArrivalTime: 27 Sep 2001 20:41:20.0659 (UTC) FILETIME=[C3AB2630:01C14794] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA03547 Sender: 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, Sep 27, 2001 03:43:54PM -0400, Melinda Shore allegedly wrote: > > R15: A Midcom agent ought to be able to have a single MIDCOM > > connection with a middlebox and use the MIDCOM > interface on the > > middlebox to interface with different middlebox > functions on the > > same middlebox interface. > > > > I'd like to drop the trailing "interface" on this one and propose > > keeping this. > > What other functions would an agent use the midcom protocol > for, besides > the one (managing rulesets) which we've already covered in other > requirements? Why would the midcom protocol be a better way to get at > those functions than some other existing protocol? I think > it's better > to drop this entirely until we know specifically what the need is. > Whatever the midcom protocol ends up doing, it will be exactly what > needs to be done and no more. I'd leave this up to the next WG. Second that. We have no intent of exposing a function decomposition in the protocol, let alone imposing it. Drop R15. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 27 17: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 ESMTP id RAA13651 for ; Thu, 27 Sep 2001 17:09: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 RAA04728; Thu, 27 Sep 2001 17:08: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 RAA04700 for ; Thu, 27 Sep 2001 17:08:07 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13634 for ; Thu, 27 Sep 2001 17:08:07 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A53314B8026E; Thu, 27 Sep 2001 17:08:03 -0400 Message-ID: <001f01c14797$e97865a0$2300000a@acmepacket.com> From: "Bob Penfield" To: "midcom" , "Melinda Shore" References: <5.1.0.14.0.20010927153421.00a6b1f0@mira-sjc5-4.cisco.com> Subject: Re: [midcom] More bullets Date: Thu, 27 Sep 2001 17:03:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Melinda Shore" To: "midcom" Sent: Thursday, September 27, 2001 3:43 PM Subject: [midcom] More bullets > R15: A Midcom agent ought to be able to have a single MIDCOM > connection with a middlebox and use the MIDCOM interface on the > middlebox to interface with different middlebox functions on the > same middlebox interface. > > I'd like to drop the trailing "interface" on this one and propose > keeping this. I believe what this is saying is that we don't want to have to establish separate midcom sessions to access different middlebox functions (e.g. one for NAT and one for firewall). I think this even extends to the ruleset in that we don't want to be forced to make seperate rulesets to establish a firewall pin-hole and a NAT binding for the same flow. Anyway, this needs to be re-worded to align it with the current terminology. I suggest: "A midcom agent ought be able to use a single midcom session with a middlebox to access different middlebox functions" OR "A midcom agent ought to be able to access different middlebox functions using a single midcom session with the middlebox" > R44: The protocol MUST permit the expression of direction to be > associated with a pin-hole. The direction MUST be specified in > terms that apply to external view of the Middlebox. This > directionality shall be expressed as 'in', 'out' or 'loopback' > (meaning both 'in' and 'out' of the same side of the same > Middlebox realm). > > The proposal is to drop this: we've already accepted R82, which gives > broad leeway in descriptions of filtering rules. I agree. > > R74: A Midcom Agent MUST be able to discover what resources are > available on a middlebox. > > Proposal: drop. We've already discussed meaningful error messages. I agree. > > R68: The Midcom Protocol MUST allow for preservation of the control > messages once the association has been established. > > Proposal: drop. I agree. > > Once we get these settled we'll tackle semantics. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 27 17:35:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13995 for ; Thu, 27 Sep 2001 17:35: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 RAA05333; Thu, 27 Sep 2001 17:32: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 RAA05305 for ; Thu, 27 Sep 2001 17:32:53 -0400 (EDT) Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13974 for ; Thu, 27 Sep 2001 17:32:51 -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 f8RKPV500902; Thu, 27 Sep 2001 13:25:31 -0700 Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Sep 2001 14:31:10 -0700 Message-ID: From: John LaCour To: "'Melinda Shore'" , midcom Subject: RE: [midcom] More bullets Date: Thu, 27 Sep 2001 14:33:21 -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 > R15: A Midcom agent ought to be able to have a single MIDCOM > connection with a middlebox and use the MIDCOM > interface on the > middlebox to interface with different middlebox > functions on the > same middlebox interface. > > I'd like to drop the trailing "interface" on this one and propose > keeping this. My understanding was the same as Bob Penfield's - that this is trying to say that you don't need to set up multiple MIDCOM sessions to request different types of rulesets be installed (or functions if you prefer). We also need to change this to reflect a requirement of the protocol and not the agent. Also, ought should be changed to MUST. I offer a slight variation on Bob Penfield's text: "The protocol MUST permit a midcom agent to use a single midcom session with a middlebox to access different middlebox functions." > R44: The protocol MUST permit the expression of direction to be > associated with a pin-hole. The direction MUST be > specified in > terms that apply to external view of the Middlebox. This > directionality shall be expressed as 'in', 'out' or 'loopback' > (meaning both 'in' and 'out' of the same side of the same > Middlebox realm). > > The proposal is to drop this: we've already accepted R82, which gives > broad leeway in descriptions of filtering rules. OK > R74: A Midcom Agent MUST be able to discover what resources are > available on a middlebox. > > Proposal: drop. We've already discussed meaningful error messages. Agreed. > R68: The Midcom Protocol MUST allow for preservation of the control > messages once the association has been established. > > Proposal: drop. Ok. > > Once we get these settled we'll tackle semantics. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > http://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 27 18:19:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14451 for ; Thu, 27 Sep 2001 18:19:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06123; Thu, 27 Sep 2001 18:17: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 SAA06092 for ; Thu, 27 Sep 2001 18:17: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 ESMTP id SAA14428 for ; Thu, 27 Sep 2001 18:17:33 -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 f8RMHJP26060 for ; Thu, 27 Sep 2001 15:17:19 -0700 (PDT) Received: from SBRIM-W2K (rtp-vpn1-277.cisco.com [10.82.225.21]) by airborne.cisco.com (Mirapoint) with SMTP id AAC55774; Thu, 27 Sep 2001 15:17:05 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Thu, 27 Sep 2001 18:17:02 -0400 Date: Thu, 27 Sep 2001 18:17:02 -0400 From: Scott Brim To: midcom Subject: Re: [midcom] More bullets Message-ID: <20010927181701.G736@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom 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 jlacour@netscreen.com on Thu, Sep 27, 2001 at 02:33:21PM -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, Sep 27, 2001 02:33:21PM -0700, John LaCour allegedly wrote: > My understanding was the same as Bob Penfield's - that this is > trying to say that you don't need to set up multiple MIDCOM > sessions to request different types of rulesets be installed A requirement phrased exactly like that would be acceptable. > (or functions if you prefer). "Function" doesn't imply "ruleset" at all. The closest you can come is that "function" refers to something like NAT or firewall. In both those cases the mechanism for "accessing" it is by communicating about rulesets. That takes you back to your first, very acceptable, phrasing, up top. > We also need to change this to reflect a requirement of the > protocol and not the agent. Also, ought should be changed to > MUST. I offer a slight variation on Bob Penfield's text: (Protocols have requirements??) > "The protocol MUST permit a midcom agent to use a > single midcom session with a middlebox to access different > middlebox functions." See top. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 27 19:11: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 ESMTP id TAA15100 for ; Thu, 27 Sep 2001 19:11:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA07424; Thu, 27 Sep 2001 19:08: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 TAA07396 for ; Thu, 27 Sep 2001 19:08:28 -0400 (EDT) Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15068 for ; Thu, 27 Sep 2001 19:08:27 -0400 (EDT) Received: from 157.54.9.108 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 27 Sep 2001 13:43:40 -0700 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); Thu, 27 Sep 2001 13:43:33 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 27 Sep 2001 13:43:34 -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); Thu, 27 Sep 2001 13:42:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] More bullets Date: Thu, 27 Sep 2001 13:42:26 -0700 Message-ID: Thread-Topic: [midcom] More bullets Thread-Index: AcFHj8r1GAO9ALR+SfShIhFH9pffTgABQxHQ From: "Christian Huitema" To: "Melinda Shore" , "midcom" X-OriginalArrivalTime: 27 Sep 2001 20:42:26.0612 (UTC) FILETIME=[EAFAC740:01C14794] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA07397 Sender: 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 > R44: The protocol MUST permit the expression of direction to be > associated with a pin-hole. The direction MUST be > specified in > terms that apply to external view of the Middlebox. This > directionality shall be expressed as 'in', 'out' or 'loopback' > (meaning both 'in' and 'out' of the same side of the same > Middlebox realm). > > The proposal is to drop this: we've already accepted R82, which gives > broad leeway in descriptions of filtering rules. Yes. > R74: A Midcom Agent MUST be able to discover what resources are > available on a middlebox. > > Proposal: drop. We've already discussed meaningful error messages. Yes. > R68: The Midcom Protocol MUST allow for preservation of the control > messages once the association has been established. > > Proposal: drop. Yes. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 27 20:15: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 ESMTP id UAA16143 for ; Thu, 27 Sep 2001 20:15: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 UAA09093; Thu, 27 Sep 2001 20:12: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 UAA09063 for ; Thu, 27 Sep 2001 20:12:13 -0400 (EDT) Received: from mail.netscreen.com (mail.netscreen.com [63.126.135.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16092 for ; Thu, 27 Sep 2001 20:12:12 -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 f8RN4t506722; Thu, 27 Sep 2001 16:04:57 -0700 Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Sep 2001 17:10:34 -0700 Message-ID: From: John LaCour To: "'Scott Brim'" , midcom Subject: RE: [midcom] More bullets Date: Thu, 27 Sep 2001 17:12:44 -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 > -----Original Message----- > From: Scott Brim [mailto:swb@employees.org] > Sent: Thursday, September 27, 2001 3:17 PM > To: midcom > Subject: Re: [midcom] More bullets > > > On Thu, Sep 27, 2001 02:33:21PM -0700, John LaCour allegedly wrote: > > My understanding was the same as Bob Penfield's - that this is > > trying to say that you don't need to set up multiple MIDCOM > > sessions to request different types of rulesets be installed > > A requirement phrased exactly like that would be acceptable. > > > (or functions if you prefer). Ok how about: The protocol MUST support the ability of an agent to use one MIDCOM session to install different types of rulesets in the same middlebox. > "Function" doesn't imply "ruleset" at all. The closest you > can come is > that "function" refers to something like NAT or firewall. In > both those > cases the mechanism for "accessing" it is by communicating about > rulesets. That takes you back to your first, very > acceptable, phrasing, > up top. > > > We also need to change this to reflect a requirement of the > > protocol and not the agent. Also, ought should be changed to > > MUST. I offer a slight variation on Bob Penfield's text: > > (Protocols have requirements??) Ok, probably should have said that we should be clear that we're talking about requirements that the protocol must support, not trying to dictate agent implementation. Obviously the two are not mutually exclusive. I'm more comfortable saying that the protocol must or must not allow something than the agent must do something. Just a personal nit. -John _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 27 20:47:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16515 for ; Thu, 27 Sep 2001 20:47: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 UAA09982; Thu, 27 Sep 2001 20:45: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 UAA09955 for ; Thu, 27 Sep 2001 20:45:41 -0400 (EDT) Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16500 for ; Thu, 27 Sep 2001 20:45:40 -0400 (EDT) Received: from 157.54.1.52 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 27 Sep 2001 17:45:05 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 27 Sep 2001 17:45:03 -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, 27 Sep 2001 17:44:54 -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.3651); Thu, 27 Sep 2001 17:44:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] More bullets Date: Thu, 27 Sep 2001 17:44:13 -0700 Message-ID: Thread-Topic: [midcom] More bullets Thread-Index: AcFHtVwElFah+0OfTlKZnug2C872fAAASpAg From: "Christian Huitema" To: "John LaCour" , "Scott Brim" , "midcom" X-OriginalArrivalTime: 28 Sep 2001 00:44:14.0173 (UTC) FILETIME=[B228E8D0:01C147B6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA09956 Sender: 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 > Ok how about: > > The protocol MUST support the ability of an agent to use one > MIDCOM session to install different types of rulesets in the > same middlebox. I would be even more specific. "When a middlebox performs both a NAT and a firewall function, it should be possible to specify firewall traversal rules and document mappings in a single ruleset." -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Thu Sep 27 23:46:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20514 for ; Thu, 27 Sep 2001 23:46: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 XAA13869; Thu, 27 Sep 2001 23:44: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 XAA13842 for ; Thu, 27 Sep 2001 23:44: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 ESMTP id XAA20439 for ; Thu, 27 Sep 2001 23:44:02 -0400 (EDT) Received: from MDUFFY ([10.1.1.18]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12TCJ1; Thu, 27 Sep 2001 23:43:35 -0400 Message-Id: <3.0.5.32.20010927234233.007cd750@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 27 Sep 2001 23:42:33 -0400 To: "Christian Huitema" , "John LaCour" , "Scott Brim" , "midcom" From: Mark Duffy Subject: RE: [midcom] More bullets 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 05:44 PM 9/27/01 -0700, Christian Huitema wrote: >> Ok how about: >> >> The protocol MUST support the ability of an agent to use one >> MIDCOM session to install different types of rulesets in the >> same middlebox. > >I would be even more specific. "When a middlebox performs both a NAT and >a firewall function, it should be possible to specify firewall traversal >rules and document mappings in a single ruleset." > >-- Christian Huitema "different types of rulesets" conveyed over one Midcom session is not the same thing as different types of action specs conveyed in the same ruleset. Lets be clear about which or both of those we want. Personally, I think the first should be a requirement; I'm not so sure about the second. Also, let's not specifically limit this to NAT, FW type middlebox functions. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 28 08:29: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 ESMTP id IAA11984 for ; Fri, 28 Sep 2001 08:29: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 IAA01914; Fri, 28 Sep 2001 08:24: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 IAA01885 for ; Fri, 28 Sep 2001 08:24:08 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11865 for ; Fri, 28 Sep 2001 08:24:02 -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 f8SCNaq18950 for ; Fri, 28 Sep 2001 05:23:36 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-148.cisco.com [10.21.96.148]) by airborne.cisco.com (Mirapoint) with SMTP id AAC61776; Fri, 28 Sep 2001 05:23:34 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Fri, 28 Sep 2001 08:23:36 -0400 Date: Fri, 28 Sep 2001 08:23:35 -0400 From: Scott Brim To: midcom Subject: Re: [midcom] More bullets Message-ID: <20010928082335.D1524@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom 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 jlacour@netscreen.com on Thu, Sep 27, 2001 at 05:12:44PM -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, Sep 27, 2001 05:12:44PM -0700, John LaCour allegedly wrote: > Ok how about: > > The protocol MUST support the ability of an agent to use one > MIDCOM session to install different types of rulesets in the > same middlebox. I question "types of rulesets". There is probably only one "type" of ruleset, with multiple possible action rules (which may or may not be more than one type). Then again, this isn't some ITU standard we're working on here, it's just requirements for the next working group, so the above is good enough. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 28 08:36:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12316 for ; Fri, 28 Sep 2001 08:36: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 IAA01976; Fri, 28 Sep 2001 08:25: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 IAA01944 for ; Fri, 28 Sep 2001 08:25:45 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11910 for ; Fri, 28 Sep 2001 08:25:38 -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 f8SCPPP17177 for ; Fri, 28 Sep 2001 05:25:25 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-148.cisco.com [10.21.96.148]) by airborne.cisco.com (Mirapoint) with SMTP id AAC61784; Fri, 28 Sep 2001 05:25:11 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Fri, 28 Sep 2001 08:25:12 -0400 Date: Fri, 28 Sep 2001 08:25:12 -0400 From: Scott Brim To: midcom Subject: Re: [midcom] More bullets Message-ID: <20010928082512.E1524@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom References: <3.0.5.32.20010927234233.007cd750@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.20010927234233.007cd750@email.quarrytech.com>; from mduffy@quarrytech.com on Thu, Sep 27, 2001 at 11:42:33PM -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On Thu, Sep 27, 2001 11:42:33PM -0400, Mark Duffy allegedly wrote: > At 05:44 PM 9/27/01 -0700, Christian Huitema wrote: > >> Ok how about: > >> > >> The protocol MUST support the ability of an agent to use one > >> MIDCOM session to install different types of rulesets in the > >> same middlebox. > > > >I would be even more specific. "When a middlebox performs both a NAT and > >a firewall function, it should be possible to specify firewall traversal > >rules and document mappings in a single ruleset." > > > >-- Christian Huitema > > "different types of rulesets" conveyed over one Midcom session is not the > same thing as different types of action specs conveyed in the same ruleset. > Lets be clear about which or both of those we want. Personally, I think > the first should be a requirement; I'm not so sure about the second. > > Also, let's not specifically limit this to NAT, FW type middlebox functions. > Right. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 28 11:31: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 ESMTP id LAA17624 for ; Fri, 28 Sep 2001 11:31: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 LAA06546; Fri, 28 Sep 2001 11:22: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 LAA06516 for ; Fri, 28 Sep 2001 11:22:13 -0400 (EDT) Received: from WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com ([131.107.3.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17433 for ; Fri, 28 Sep 2001 11:22:07 -0400 (EDT) Received: from win-hub-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.229]) by WIN-INET-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Fri, 28 Sep 2001 08:19:50 -0700 Received: from 157.54.5.226 by win-hub-01.wingroup.windeploy.ntdev.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 28 Sep 2001 08:19:50 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-hub-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.3651); Fri, 28 Sep 2001 08:19:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] More bullets Date: Fri, 28 Sep 2001 08:19:50 -0700 Message-ID: Thread-Topic: [midcom] More bullets Thread-Index: AcFIG08bux0C3IcQRP2UzPEPgJJjxgAFXJTg From: "Christian Huitema" To: "Scott Brim" , "midcom" X-OriginalArrivalTime: 28 Sep 2001 15:19:50.0716 (UTC) FILETIME=[04612FC0:01C14831] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA06517 Sender: 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 would be even more specific. "When a middlebox performs > both a NAT and > > >a firewall function, it should be possible to specify > firewall traversal > > >rules and document mappings in a single ruleset." > > > > > >-- Christian Huitema > > > > "different types of rulesets" conveyed over one Midcom > session is not the > > same thing as different types of action specs conveyed in > the same ruleset. > > Lets be clear about which or both of those we want. > Personally, I think > > the first should be a requirement; I'm not so sure about the second. > > > > Also, let's not specifically limit this to NAT, FW type > middlebox functions. The point is not to limit this to NAT, FW, but to make sure that NAT & FW are well covered. After all, this *is* the priority of this working group. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 28 11:44:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17940 for ; Fri, 28 Sep 2001 11:44: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 LAA07317; Fri, 28 Sep 2001 11:43: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 LAA07287 for ; Fri, 28 Sep 2001 11:43:06 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17923 for ; Fri, 28 Sep 2001 11:42:59 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AA834509019C; Fri, 28 Sep 2001 11:42:59 -0400 Message-ID: <005101c14833$7b076a20$2300000a@acmepacket.com> From: "Bob Penfield" To: "Christian Huitema" , "John LaCour" , "Scott Brim" , "midcom" , "Mark Duffy" References: <3.0.5.32.20010927234233.007cd750@email.quarrytech.com> Subject: Re: [midcom] More bullets Date: Fri, 28 Sep 2001 11:37:28 -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: "Mark Duffy" To: "Christian Huitema" ; "John LaCour" ; "Scott Brim" ; "midcom" Sent: Thursday, September 27, 2001 11:42 PM Subject: RE: [midcom] More bullets > At 05:44 PM 9/27/01 -0700, Christian Huitema wrote: > >> Ok how about: > >> > >> The protocol MUST support the ability of an agent to use one > >> MIDCOM session to install different types of rulesets in the > >> same middlebox. > > > >I would be even more specific. "When a middlebox performs both a NAT and > >a firewall function, it should be possible to specify firewall traversal > >rules and document mappings in a single ruleset." > > > >-- Christian Huitema > > "different types of rulesets" conveyed over one Midcom session is not the > same thing as different types of action specs conveyed in the same ruleset. > Lets be clear about which or both of those we want. Personally, I think > the first should be a requirement; I'm not so sure about the second. > > Also, let's not specifically limit this to NAT, FW type middlebox functions. > I like Christian's requirement. It is highly desirable to have a single ruleset permit the flow and establish the NAT bindings. Isn't that why we called it a ruleset since it can have multiple rules (filters & actions)? However, I agree we might want more general language. If we make a requirement for the ability to define a ruleset that includes multiple functions/actions, that would cover the "one session to install different types..". How about this? The protocol MUST support the ability of an agent to install a ruleset that includes multiple types of middlebox functions (e.g. firewall and NAT). (-:bob _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 28 12:14: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 ESMTP id MAB18673 for ; Fri, 28 Sep 2001 12:14: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 MAA08860; Fri, 28 Sep 2001 12:08: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 MAA08831 for ; Fri, 28 Sep 2001 12:08:33 -0400 (EDT) Received: from qtech1.quarrytech.com (email.quarrytech.com [4.17.144.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18562 for ; Fri, 28 Sep 2001 12:08:26 -0400 (EDT) Received: from MDUFFY ([10.1.3.114]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TB12TDF9; Fri, 28 Sep 2001 12:08:02 -0400 Message-Id: <3.0.5.32.20010928120702.0094a9e0@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 28 Sep 2001 12:07:02 -0400 To: "Bob Penfield" , "Christian Huitema" , "John LaCour" , "Scott Brim" , "midcom" From: Mark Duffy Subject: Re: [midcom] More bullets In-Reply-To: <005101c14833$7b076a20$2300000a@acmepacket.com> References: <3.0.5.32.20010927234233.007cd750@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org >How about this? > >The protocol MUST support the ability of an agent to install a ruleset that >includes multiple types of middlebox functions (e.g. firewall and NAT). > >(-:bob Fine. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Fri Sep 28 12:21:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18824 for ; Fri, 28 Sep 2001 12:21: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 MAA09048; Fri, 28 Sep 2001 12:14:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09020 for ; Fri, 28 Sep 2001 12:14:08 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18669 for ; Fri, 28 Sep 2001 12:14:00 -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 f8SGDaq04058 for ; Fri, 28 Sep 2001 09:13:36 -0700 (PDT) Received: from SBRIM-W2K (sjc-vpn1-148.cisco.com [10.21.96.148]) by airborne.cisco.com (Mirapoint) with SMTP id AAC63829; Fri, 28 Sep 2001 09:13:32 -0700 (PDT) Received: by SBRIM-W2K (sSMTP sendmail emulation); Fri, 28 Sep 2001 12:13:32 -0400 Date: Fri, 28 Sep 2001 12:13:32 -0400 From: Scott Brim To: midcom Subject: Re: [midcom] More bullets Message-ID: <20010928121332.K1524@SBRIM-W2K> Mail-Followup-To: Scott Brim , midcom References: <3.0.5.32.20010927234233.007cd750@email.quarrytech.com> <005101c14833$7b076a20$2300000a@acmepacket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <005101c14833$7b076a20$2300000a@acmepacket.com>; from bpenfield@acmepacket.com on Fri, Sep 28, 2001 at 11:37:28AM -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 Fri, Sep 28, 2001 11:37:28AM -0400, Bob Penfield allegedly wrote: > > >I would be even more specific. "When a middlebox performs both a > > >NAT and a firewall function, it should be possible to specify > > >firewall traversal rules and document mappings in a single > > >ruleset." > > > > > >-- Christian Huitema > I like Christian's requirement. It is highly desirable to have a > single ruleset permit the flow and establish the NAT bindings. Yes. > Isn't > that why we called it a ruleset since it can have multiple rules > (filters & actions)? Filters and actions are a different matter. This is multiple actions. > However, I agree we might want more general > language. If we make a requirement for the ability to define a ruleset > that includes multiple functions/actions, that would cover the "one > session to install different types..". > > How about this? > > The protocol MUST support the ability of an agent to install a ruleset > that includes multiple types of middlebox functions (e.g. firewall and > NAT). Rulesets include specifications of actions. A ruleset does not include a "function" in the sense you seem to be using the term -- for example a firewall function. A ruleset may include a rule which would be used as input to a firewall function. I don't think the exact words matter much, as long as they don't thoroughly confuse the WG that comes after us. That's all I'm trying to avoid. _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom From midcom-admin@ietf.org Sun Sep 30 02:03: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 ESMTP id CAA10102 for ; Sun, 30 Sep 2001 02:03: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 BAA12980; Sun, 30 Sep 2001 01:57: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 BAA12940 for ; Sun, 30 Sep 2001 01:57:30 -0400 (EDT) Received: from fog ([211.116.22.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05788 for ; Sun, 30 Sep 2001 01:57:27 -0400 (EDT) Message-Id: <200109300557.BAA05788@ietf.org> From: =?ks_c_5601-1987?B?xvex173DvbrF2w==?= To: midcom@ietf.org Date: Sun, 30 Sep 2001 14:57:09 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0147_01C0F30A.93A57C00" X-Priority: 3 Subject: [midcom] =?ks_c_5601-1987?B?W0ZvZ10gsc2758DHIMioxuTAzMH2uKYgMTAwuLi47b+hsNQgvsu3wbXluLO0z7TZLg==?= Sender: 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_0147_01C0F30A.93A57C00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 Ojo6IEludHJvZHVjZSBvZiBGT0cgU1lTVEVNIDo6OiAgICAgICAgICAgICAgICAgICAgICAg IKHhICCh4SANCiAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KIKLAIMClILvnwMzGriwg uLi16bHiuLggx8+46SC1yLTZsO0gu/2wosfPvcq0z7HuPw0KIMfRufi4uCC+srDtILn2uK69 xyCwx7Chv+Q/IDG17sC7IMfPseK6uLTZtMIgMbXuwLsgwfbFsLHisKEgtPUgvu63xrTZtMIg uLvAzCDA1r3AtM+02S4NCiC4uLXpuOkgxevH0bTZLi6+xrTVtM+02S4hDQogu+e+98iutOu4 piDF68fYILT1IMS/wfogu+fAzMauuKYgwKfH0SCx4rndwLi3ziDA2773x9i+3yC1x7TCsMUg vsa9w8HSPw0KIA0KIKLAILGksO20wiDA+sD9t84gtcezqr/kPw0KIL73uau1tSC52bvbtaUg sO2wtLD8uK60wiC0qbChx8+zqr/kPw0KILrxvc6w1Li4ILi4tem46SDBwcC6ILvnwMzGrrCh ILOqv8K02bDtILv9sKLHz73KtM+x7j8NCiANCiCiwCDHz7Dtvc3AuiCwzcC6ILi5sO0guvG/ 68C6ILrOwbfHz7DtLi4uLiANCiCwxsGkx8/B9iC4try8v+QhIMD6t8XH0SCwobDdwLi3ziDD 1rDtwMcgu+fAzMauuKYgsbjD4MfPsNq9wLTPtNkuDQogxvex17+hvK20wiDApbvnwMzGrrim ILCzud/H2CDB1rTCILDNwLi3ziCzobOqwfYgvsq9wLTPtNkuDQogseLIub+hvK0guLbEycbD LCCx17iusO0gsO2wtLD8uK6x7sH2ISEhDQogxvex17+hvK20wiC48LXnILDNwLsgw6XA08H9 tM+02S4NCiANCiA6Ojo6OiDC/MG2sLO537vnwMzGriCi0SDGxLzSs6qx4iAgKHd3dy5mYXNv bmFraS5jb20pIA0KICAgICAgICAgICAgICCh4SAgoeEgICAgICAgICAgDQogwK+89sDHILvn wMzGrrimILCzud/H0SC9x7fCwLsgsKHB+CDG97HXvcO9usXbv6EguMOw3Lq4vLy/5CEhICAg w9aw7cDHILzux8649MC7ILCusNQgtckgsM3A1LTPtNkuDQogsKGw1L+hIMDOxde4rr7uuLgg x9G02bDtILzVtNTAzCC/wLOqv+Q/ICAgvsa01bTPtNkuILzVtNTAuyC60revvt8gv8DB9r/k Lg0KILzVtNS4uCC/wLjpIMD6wP23ziDGyLius6q/5D8NCiDDtsD6x9EgvK268b26v80gv8+6 rsfRILDtsLSw/LiusKEgvvjAzLTCIMD9tOu3ziC8urD4x9IgvPawoSC++L3AtM+02S4NCiAN CiDG97HXv6G8rbTCILzux8649MC7ILCzud/H2CDB1rTCILDNwLi3ziCzobOqwfYgvsq9wLTP tNkuDQogseLIub+hvK0guLbEycbDLCCx17iusO0gsO2wtLD8uK6x7sH2ISEhDQogxvex17+h vK20wiC48LXnILDNwLsgw6XA08H9tM+02S4NCiANCiA6Ojo6OiDC/MG2sLO537vnwMzGriA6 ILG5uc7Eq7XlICC87sfOuPQsILvvvLq49CAgtOXExCAgICAgICAgICAgICAgoeEgIKHhICAg ICAgICAgIA0KIMPrvve758DMxq4sILOytem1tSC02SDA1rTCtaUuLi4gvu62u7DUIMfPwfY/ IMD6yPEgxvex17+hILjDsNzB1ry8v+QuILjFsObD6773u+fAzMauuKYgwabA28fRILHivPq3 wrD6ILDmx+jAuyC52cXBwLi3ziCxzbvnwMcgIA0KIMPrvve758DMxq64piDDpcDTwf20z7TZ Lg0KIA0KIDo6Ojo6IML8wbaws7nfu+fAzMauIDoguMWw5sPrvve758DMxq4gICh3d3cubWtz Y291dC5jb20pICAgICAgICAgICAgIKHhICCh4SAgICAgICAgDQogRk9HtMIuLi4nRmlyZSBv ZiBHZW5pZXMntvO0wiC25sC4t84gwMy0wiDAzsXNs90gsPiwo8DHIMPWsO2woSC1x7DatNm0 wiDAx7nMuKYgs7vG98fPsO0gwNa9wLTPtNkuIMD6yPEgot/G97HXvcO9usXbwLogILG5s7sg w9aw7cDHIA0KILHivPrAuyC52cXBwLi3ziDH0SDApbvnwMzGriwgvO7Hzrj0ILnXIMPrvve7 58DMxq4gsbjD4CDA/LmuIMClv6HAzMGvvcPA1LTPtNkuDQogsc2758DHILnfwPzAuyDA+sjx IMb3sde/zSDH1LKyIMfSILz2IMDWwLi46SC09SDBwbDavcC0z7TZLiC80sHfx9EgvcOwoyCz u8HWvMW8rSCwqLvnx9W0z7TZLiAgICAgIA0KILHNx8/AxyDAzLjewM8gwda80rTCIMD8vcPI uCC51yCw/LfDIMClu+fAzMauILnXILDUvcPGxyC17r+hvK0gvPbB/cfRILDNwLi3ziDAzLje wM8gwda80iAgv9zAxyCws8DOwaS6uLTCILChwfaw7SDA1sH2IL7KvcC0z7TZLg0KIMDMIGUt bWFpbMC6ILnfvcXA/L/rwNS0z7TZLiC53rHiuKYgv/jHz8H2IL7KwLi9w7jpICe89r3FsMW6 zie4piAgtK23ryDB1r3KvcO/wC4NCiANCiCiuSDA/MitufjIoyA6IDAyKTU2My04MjgwICjT 2ykNCiCiuSBFo61NQUlMIDogc2t5MDA3QGZvZy5jby5rcg0KIKK5IMioxuTAzMH2IDogot/G 97HXvcO9usXbICAoaHR0cDovL3d3dy5mb2cuY28ua3IpDQogICAgICAgICAgICAgICAgICAg IA0KIENvcHlyaWdodChjKSAyMDAxIEZPRyBTWVNURU0gQWxsIHJpZ2h0cyByZXNlcnZlZC4g IA0KICAgICAgICA= ------=_NextPart_000_0147_01C0F30A.93A57C00 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT46OjogSW50cm9kdWNlIG9mIEZPRyBTWVNURU0gOjo6 IDwvdGl0bGU+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD1ldWMta3IiPg0KPGxpbmsgcmVsPSJzdHlsZXNoZWV0IiB0eXBl PSJ0ZXh0L2NzcyIgaHJlZj0iaHR0cDovL3d3dy5mb2cuY28ua3IvZm9nLmNzcyI+DQo8L2hl YWQ+DQoNCjxib2R5IGJhY2tncm91bmQ9Imh0dHA6Ly93d3cuZm9nLmNvLmtyL2ltYWdlcy90 ZW1wL2JhLmdpZiIgdG9wbWFyZ2luPSIwIiBsZWZ0bWFyZ2luPSIwIj4NCjx0YWJsZSB3aWR0 aD0iODAwIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgYWxp Z249ImNlbnRlciIgYmdjb2xvcj0iRkZGRkZGIj4NCiAgPHRyID4gDQogICAgPHRkIGNvbHNw YW49IjQiIGhlaWdodD0iMjAiIGJhY2tncm91bmQ9Imh0dHA6Ly93d3cuZm9nLmNvLmtyL2lt YWdlcy90ZW1wL2JhLmdpZiI+Jm5ic3A7PC90ZD4NCiAgPC90cj4NCiAgPHRyPiANCiAgICA8 dGQgd2lkdGg9IjYwIiBoZWlnaHQ9IjIwIj4mbmJzcDs8L3RkPg0KICAgIDx0ZCB3aWR0aD0i NzQwIj4mbmJzcDs8L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCBjb2xzcGFuPSIy Ij48YSBocmVmPSJodHRwOi8vd3d3LmZvZy5jby5rciIgdGFyZ2V0PSJfYmxhbmsiPjxpbWcg c3JjPSJodHRwOi8vd3d3LmZvZy5jby5rci9pbWFnZXMvdGVtcC9sb2dvLmdpZiIgd2lkdGg9 IjE2MCIgaGVpZ2h0PSIzMSIgYm9yZGVyPSIwIiBhbHQ9IkZPRyBzeXN0ZW0iPjwvYT4gDQog ICAgPC90ZD4NCiAgPC90cj4NCiAgPHRyPiANCiAgICA8dGQgY29sc3Bhbj0iMiIgYWxpZ249 ImNlbnRlciI+PGltZyBzcmM9Imh0dHA6Ly93d3cuZm9nLmNvLmtyL2ltYWdlcy90ZW1wL2lt Zy5naWYiIHdpZHRoPSI4MDAiIGhlaWdodD0iODUiPjwvdGQ+DQogIDwvdHI+DQogIDx0ciBi Z2NvbG9yPSJFN0U3RTYiPiANCiAgICA8dGQgY29sc3Bhbj0iMiIgaGVpZ2h0PSIyMCI+Jm5i c3A7PC90ZD4NCiAgPC90cj4NCiAgPHRyPiANCiAgICA8dGQgY29sc3Bhbj0iMiIgaGVpZ2h0 PSIxMTAiIGJnY29sb3I9IkU3RTdFNiIgPjxiPjxmb250IGNvbG9yPSIjMDA2NkNDIiBzaXpl PSIxIj48aW1nIHNyYz0iaHR0cDovL3d3dy5mb2cuY28ua3IvaW1hZ2VzL3RlbXAvaWNvbi5n aWYiIHdpZHRoPSI1MyIgaGVpZ2h0PSIyNCIgYWxpZ249ImFic21pZGRsZSI+oeEgDQogICAg ICCh4SA8L2ZvbnQ+PC9iPjxpbWcgc3JjPSJodHRwOi8vd3d3LmZvZy5jby5rci9pbWFnZXMv dGVtcC90aXRsZTEuZ2lmIiB3aWR0aD0iMzExIiBoZWlnaHQ9IjMwIiBhbGlnbj0iYWJzbWlk ZGxlIj48YnI+DQogICAgICAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGltZyBzcmM9Imh0dHA6Ly93d3cu Zm9nLmNvLmtyL2ltYWdlcy90ZW1wL3RpdGxlMS0xLmdpZiIgd2lkdGg9IjUwNSIgaGVpZ2h0 PSI5NyI+IA0KICAgIDwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkPiZuYnNwOzwv dGQ+DQogICAgPHRkPiA8YnI+DQogICAgICA8Zm9udCBjb2xvcj0iI0ZGNTQwMCI+osAgwKUg u+fAzMauLCC4uLXpseK4uCDHz7jpILXItNmw7SC7/bCix8+9yrTPse4/PC9mb250Pjxicj4N CiAgICAgIMfRufi4uCC+srDtILn2uK69xyCwx7Chv+Q/IDG17sC7IMfPseK6uLTZtMIgMbXu wLsgwfbFsLHisKEgtPUgvu63xrTZtMIguLvAzCDA1r3AtM+02S48YnI+DQogICAgICC4uLXp uOkgxevH0bTZLi6+xrTVtM+02S4hPGJyPg0KICAgICAgu+e+98iutOu4piDF68fYILT1IMS/ wfogu+fAzMauuKYgwKfH0SCx4rndwLi3ziDA2773x9i+3yC1x7TCsMUgvsa9w8HSPzxicj4N CiAgICAgIDxicj4NCiAgICAgIDxmb250IGNvbG9yPSIjRkY1NDAwIj6iwCCxpLDttMIgwPrA /bfOILXHs6q/5D88L2ZvbnQ+PGJyPg0KICAgICAgvve5q7W1ILnZu9u1pSCw7bC0sPy4rrTC ILSpsKHHz7Oqv+Q/PGJyPg0KICAgICAguvG9zrDUuLgguLi16bjpIMHBwLogu+fAzMausKEg s6q/wrTZsO0gu/2wosfPvcq0z7HuPzxicj4NCiAgICAgIDxicj4NCiAgICAgIDxmb250IGNv bG9yPSIjRkY1NDAwIj6iwCDHz7Dtvc3AuiCwzcC6ILi5sO0guvG/68C6ILrOwbfHz7DtLi4u LiA8L2ZvbnQ+PGJyPg0KICAgICAgsMbBpMfPwfYguLa8vL/kISDA+rfFx9EgsKGw3cC4t84g w9aw7cDHILvnwMzGrrimILG4w+DHz7DavcC0z7TZLjxicj4NCiAgICAgIMb3sde/obyttMIg wKW758DMxq64piCws7nfx9ggwda0wiCwzcC4t84gs6GzqsH2IL7KvcC0z7TZLjxicj4NCiAg ICAgILHiyLm/obytILi2xMnGwywgsde4rrDtILDtsLSw/Liuse7B9iEhITxicj4NCiAgICAg IMb3sde/obyttMIguPC15yCwzcC7IMOlwNPB/bTPtNkuPGJyPg0KICAgICAgPGJyPg0KICAg ICAgPGZvbnQgY29sb3I9IiNENjg2MzUiPjxiPjo6Ojo6IML8wbaws7nfu+fAzMauIDwvYj6i 0SA8YSBocmVmPSJodHRwOi8vd3d3LmZhc29uYWtpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxm b250IGNvbG9yPSIjQzQ2MzAyIj7GxLzSs6qx4iANCiAgICAgICh3d3cuZmFzb25ha2kuY29t KSA8L2ZvbnQ+PC9hPjwvZm9udD48YnI+DQogICAgPC90ZD4NCiAgPC90cj4NCiAgPHRyPiAN CiAgICA8dGQ+Jm5ic3A7PC90ZD4NCiAgICA8dGQ+Jm5ic3A7IDwvdGQ+DQogIDwvdHI+DQog IDx0cj4gDQogICAgPHRkIGJnY29sb3I9IiNBRENGRUUiIGNvbHNwYW49IjIiIGhlaWdodD0i MSI+PC90ZD4NCiAgPC90cj4NCiAgPHRyPiANCiAgICA8dGQgY29sc3Bhbj0iMiIgYmdjb2xv cj0iI0U2RjNGRiIgPjxiPjxmb250IGNvbG9yPSIjMDA2NkNDIj48Zm9udCBzaXplPSIxIj48 aW1nIHNyYz0iaHR0cDovL3d3dy5mb2cuY28ua3IvaW1hZ2VzL3RlbXAvaWNvbi5naWYiIHdp ZHRoPSI1MyIgaGVpZ2h0PSIyNCIgYWxpZ249ImFic21pZGRsZSI+oeEgDQogICAgICCh4Twv Zm9udD4gPGltZyBzcmM9Imh0dHA6Ly93d3cuZm9nLmNvLmtyL2ltYWdlcy90ZW1wL3RpdGxl Mi5naWYiIHdpZHRoPSIyOTgiIGhlaWdodD0iMzAiIGFsaWduPSJhYnNtaWRkbGUiPjwvZm9u dD48L2I+IA0KICAgIDwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIGJnY29sb3I9 IiNBRENGRUUiIGNvbHNwYW49IjIiIGhlaWdodD0iMSI+PC90ZD4NCiAgPC90cj4NCiAgPHRy PiANCiAgICA8dGQ+Jm5ic3A7PC90ZD4NCiAgICA8dGQ+PGJyPg0KICAgICAgwK+89sDHILvn wMzGrrimILCzud/H0SC9x7fCwLsgsKHB+CDG97HXvcO9usXbv6EguMOw3Lq4vLy/5CEhICZu YnNwOyDD1rDtwMcgvO7Hzrj0wLsgsK6w1CC1ySCwzcDUtM+02S48YnI+DQogICAgICCwobDU v6EgwM7F17iuvu64uCDH0bTZsO0gvNW01MDMIL/As6q/5D8gJm5ic3A7IL7GtNW0z7TZLiC8 1bTUwLsgutK3r77fIL/Awfa/5C48YnI+DQogICAgICC81bTUuLggv8C46SDA+sD9t84gxsi4 rrOqv+Q/PGJyPg0KICAgICAgw7bA+sfRILytuvG9ur/NIL/Puq7H0SCw7bC0sPy4rrChIL74 wMy0wiDA/bTrt84gvLqw+MfSILz2sKEgvvi9wLTPtNkuPGJyPg0KICAgICAgPGJyPg0KICAg ICAgxvex17+hvK20wiC87sfOuPTAuyCws7nfx9ggwda0wiCwzcC4t84gs6GzqsH2IL7KvcC0 z7TZLjxicj4NCiAgICAgIDxmb250IGNvbG9yPSIjRkY1NDAwIj6x4si5v6G8rSC4tsTJxsMs ILHXuK6w7SCw7bC0sPy4rrHuwfYhISE8YnI+DQogICAgICA8Yj7G97HXv6G8rbTCILjwtecg sM3AuyDDpcDTwf20z7TZLjwvYj48L2ZvbnQ+PGJyPg0KICAgICAgPGJyPg0KICAgICAgPGZv bnQgY29sb3I9IiNENjg2MzUiPjxiPjo6Ojo6IML8wbaws7nfu+fAzMauIDogPC9iPjxhIGhy ZWY9Imh0dHA6Ly93d3cucGFzc2NpdHkuY28ua3IiIHRhcmdldD0iX2JsYW5rIj48Zm9udCBj b2xvcj0iI0M0NjMwMiI+sbm5zsSrteUgDQogICAgICC87sfOuPQ8L2ZvbnQ+PC9hPiwgPGEg aHJlZj0iaHR0cDovL3d3dy5zYW1zdW5nbWFsbC5jby5rciIgdGFyZ2V0PSJfYmxhbmsiPjxm b250IGNvbG9yPSIjQzQ2MzAyIj6777y6uPQgDQogICAgICC05cTEPC9mb250PjwvYT48L2Zv bnQ+IDwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkPiZuYnNwOzwvdGQ+DQogICAg PHRkPiZuYnNwOyA8L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCBiZ2NvbG9yPSIj QURDRkVFIiBjb2xzcGFuPSIyIiBoZWlnaHQ9IjEiPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4g DQogICAgPHRkIGNvbHNwYW49IjIiIGJnY29sb3I9IiNFNkYzRkYiID48Zm9udCBjb2xvcj0i IzAwNjZDQyI+PGZvbnQgc2l6ZT0iMSI+PGI+PGZvbnQgY29sb3I9IiMwMDY2Q0MiPjxmb250 IHNpemU9IjEiPjxpbWcgc3JjPSJodHRwOi8vd3d3LmZvZy5jby5rci9pbWFnZXMvdGVtcC9p Y29uLmdpZiIgd2lkdGg9IjUzIiBoZWlnaHQ9IjI0IiBhbGlnbj0iYWJzbWlkZGxlIj48L2Zv bnQ+PC9mb250PjwvYj6h4SANCiAgICAgIKHhPC9mb250PiA8L2ZvbnQ+PGltZyBzcmM9Imh0 dHA6Ly93d3cuZm9nLmNvLmtyL2ltYWdlcy90ZW1wL3RpdGxlMy5naWYiIHdpZHRoPSIyNjAi IGhlaWdodD0iMzAiIGFsaWduPSJhYnNtaWRkbGUiPiANCiAgICA8L3RkPg0KICA8L3RyPg0K ICA8dHI+IA0KICAgIDx0ZCBiZ2NvbG9yPSIjQURDRkVFIiBjb2xzcGFuPSIyIiBoZWlnaHQ9 IjEiPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkPiZuYnNwOzwvdGQ+DQogICAg PHRkPiA8YnI+DQogICAgICDD6773u+fAzMauLCCzsrXptbUgtNkgwNa0wrWlLi4uIL7utruw 1CDHz8H2PyDA+sjxIMb3sde/oSC4w7Dcwda8vL/kLiC4xbDmw+u+97vnwMzGrrimIMGmwNvH 0SCx4rz6t8Kw+iCw5sfowLsgudnFwcC4t84gsc2758DHIA0KICAgICAgPGJyPg0KICAgICAg w+u+97vnwMzGrrimIMOlwNPB/bTPtNkuPGJyPg0KICAgICAgPGZvbnQgY29sb3I9IiNENjg2 MzUiPjxiPjxicj4NCiAgICAgIDo6Ojo6IML8wbaws7nfu+fAzMauIDogPC9iPjxhIGhyZWY9 Imh0dHA6Ly93d3cubWtzY291dC5jb20iIHRhcmdldD0iX2JsYW5rIj48Zm9udCBjb2xvcj0i I0M0NjMwMiI+uMWw5sPrvve758DMxq4gDQogICAgICAod3d3Lm1rc2NvdXQuY29tKTwvZm9u dD48L2E+PC9mb250PiA8L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZD4mbmJzcDs8 L3RkPg0KICAgIDx0ZD48Zm9udCBjb2xvcj0iIzAwNjZDQyI+PGZvbnQgc2l6ZT0iMSI+PGI+ PGZvbnQgY29sb3I9IiMwMDY2Q0MiPjwvZm9udD48L2I+PC9mb250PjwvZm9udD4gDQogICAg PC90ZD4NCiAgPC90cj4NCiAgPHRyPiANCiAgICA8dGQgYmdjb2xvcj0iI0FEQ0ZFRSIgY29s c3Bhbj0iMiIgaGVpZ2h0PSIxIj48L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCBj b2xzcGFuPSIyIiBiZ2NvbG9yPSIjRTZGM0ZGIiA+PGZvbnQgY29sb3I9IiMwMDY2Q0MiPjxm b250IGNvbG9yPSIjMDA2NkNDIj48Zm9udCBzaXplPSIxIj48Yj48Zm9udCBjb2xvcj0iIzAw NjZDQyI+PGZvbnQgc2l6ZT0iMSI+PGltZyBzcmM9Imh0dHA6Ly93d3cuZm9nLmNvLmtyL2lt YWdlcy90ZW1wL2ljb24uZ2lmIiB3aWR0aD0iNTMiIGhlaWdodD0iMjQiIGFsaWduPSJhYnNt aWRkbGUiPjwvZm9udD48L2ZvbnQ+PC9iPjwvZm9udD48L2ZvbnQ+PGZvbnQgc2l6ZT0iMSI+ oeEgDQogICAgICCh4TwvZm9udD48L2ZvbnQ+PGltZyBzcmM9Imh0dHA6Ly93d3cuZm9nLmNv LmtyL2ltYWdlcy90ZW1wL3RpdGxlNC5naWYiIHdpZHRoPSIxNTUiIGhlaWdodD0iMzAiIGFs aWduPSJhYnNtaWRkbGUiPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIGJnY29s b3I9IiNBRENGRUUiIGNvbHNwYW49IjIiIGhlaWdodD0iMSI+PC90ZD4NCiAgPC90cj4NCiAg PHRyPiANCiAgICA8dGQ+Jm5ic3A7PC90ZD4NCiAgICA8dGQ+PGJyPg0KICAgICAgRk9HtMIu Li4nRmlyZSBvZiBHZW5pZXMntvO0wiC25sC4t84gwMy0wiDAzsXNs90gsPiwo8DHIMPWsO2w oSC1x7DatNm0wiDAx7nMuKYgs7vG98fPsO0gwNa9wLTPtNkuIMD6yPEgot/G97HXvcO9usXb wLogDQogICAgICCxubO7IMPWsO3AxyA8YnI+DQogICAgICCx4rz6wLsgudnFwcC4t84gx9Eg wKW758DMxq4sILzux8649CC51yDD6773u+fAzMauILG4w+AgwPy5riDApb+hwMzBr73DwNS0 z7TZLjxicj4NCiAgICAgILHNu+fAxyC538D8wLsgwPrI8SDG97HXv80gx9SysiDH0iC89iDA 1sC4uOkgtPUgwcGw2r3AtM+02S4gvNLB38fRIL3DsKMgs7vB1rzFvK0gsKi758fVtM+02S4g PC90ZD4NCiAgPC90cj4NCiAgPHRyPiANCiAgICA8dGQgaGVpZ2h0PSIzMCI+Jm5ic3A7PC90 ZD4NCiAgICA8dGQ+PGJyPg0KICAgICAgPGZvbnQgY29sb3I9IiMwMDY2NjYiPrHNx8/AxyDA zLjewM8gwda80rTCIMD8vcPIuCC51yCw/LfDIMClu+fAzMauILnXILDUvcPGxyC17r+hvK0g vPbB/cfRILDNwLi3ziDAzLjewM8gwda80iANCiAgICAgIL/cwMcgsLPAzsGkuri0wiCwocH2 sO0gwNbB9iC+yr3AtM+02S48YnI+DQogICAgICDAzCBlLW1haWzAuiC5373FwPy/68DUtM+0 2S4gud6x4rimIL/4x8/B9iC+ysC4vcO46SA8YSBocmVmPSJtYWlsdG86c2t5MDA3QGZvZy5j by5rciI+J7z2vcWwxbrOJzwvYT64piANCiAgICAgILStt68gwda9yr3Dv8AuPC9mb250Pjxi cj4NCiAgICAgIDxicj4NCiAgICAgIDxmb250IGNvbG9yPSIjYzIxMTExIj6iuSDA/MitufjI oyA6IDAyKTU2My04MjgwICjT2yk8YnI+DQogICAgICCiuSBFo61NQUlMIDogPGEgaHJlZj0i bWFpbHRvOmZvZ0Bmb2cuY28ua3IiPjxmb250IGNvbG9yPSIjRTA0MTQxIj5za3kwMDdAZm9n LmNvLmtyPC9mb250PjwvYT48YnI+DQogICAgICCiuSDIqMbkwMzB9iA6IDxhIGhyZWY9Imh0 dHA6Ly93d3cuZm9nLmNvLmtyIiB0YXJnZXQ9Il9ibGFuayI+PGZvbnQgY29sb3I9IiNFMDQx NDEiPqLfxvex173DvbrF2yANCiAgICAgIChodHRwOi8vd3d3LmZvZy5jby5rcik8L2ZvbnQ+ PC9hPjwvZm9udD48YnI+DQogICAgPC90ZD4NCiAgPC90cj4NCiAgPHRyPiANCiAgICA8dGQg Y29sc3Bhbj0iMiI+Jm5ic3A7PC90ZD4NCiAgPC90cj4NCiAgPHRyPiANCiAgICA8dGQ+Jm5i c3A7PC90ZD4NCiAgICA8dGQgYWxpZ249ImNlbnRlciIgaGVpZ2h0PSI2MyI+PGEgaHJlZj0i aHR0cDovL3d3dy5mb2cuY28ua3IiPjxpbWcgc3JjPSJodHRwOi8vd3d3LmZvZy5jby5rci9p bWFnZXMvMDFmb2cvaW1nX2xvZ28uZ2lmIiB3aWR0aD0iMTI1IiBoZWlnaHQ9IjgwIiBib3Jk ZXI9IjAiPjwvYT4mbmJzcDsgDQogICAgICAmbmJzcDsgPC90ZD4NCiAgPC90cj4NCiAgPHRy PiANCiAgICA8dGQgaGVpZ2h0PSIyMCI+Jm5ic3A7PC90ZD4NCiAgICA8dGQgYWxpZ249ImNl bnRlciI+PGJyPg0KICAgICAgPGZvbnQgY29sb3I9IiM5OTk5OTkiPkNvcHlyaWdodChjKSAy MDAxIEZPRyBTWVNURU0gQWxsIHJpZ2h0cyByZXNlcnZlZC4gDQogICAgICA8YnI+DQogICAg ICA8L2ZvbnQ+IDwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIGNvbHNwYW49IjQi IGhlaWdodD0iMjAiIGJhY2tncm91bmQ9Imh0dHA6Ly93d3cuZm9nLmNvLmtyL2ltYWdlcy90 ZW1wL2JhLmdpZiI+Jm5ic3A7PC90ZD4NCiAgPC90cj4NCjwvdGFibGU+ICAgDQo8L2JvZHk+ ICAgDQo8L2h0bWw+ICAgDQoNCg== ------=_NextPart_000_0147_01C0F30A.93A57C00-- _______________________________________________ midcom mailing list midcom@ietf.org http://www1.ietf.org/mailman/listinfo/midcom