From exim@www1.ietf.org Tue Sep 2 13:00:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14998 for ; Tue, 2 Sep 2003 13:00:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEVj-0001oA-D2 for midcom-archive@odin.ietf.org; Tue, 02 Sep 2003 13:00:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82H06d6006925 for midcom-archive@odin.ietf.org; Tue, 2 Sep 2003 13:00:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEVe-0001mm-LA; Tue, 02 Sep 2003 13:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEUw-0001T3-MP for midcom@optimus.ietf.org; Tue, 02 Sep 2003 12:59:18 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14624; Tue, 2 Sep 2003 12:59:11 -0400 (EDT) Message-Id: <200309021659.MAA14624@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, 02 Sep 2003 12:59:11 -0400 Subject: [midcom] I-D ACTION:draft-ietf-nat-natmib-06.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Definitions of Managed Objects for Network Address Translators (NAT) Author(s) : R. Raghunarayan, N. Pai, R. Rohit, C. Wang, P. Srisuresh Filename : draft-ietf-nat-natmib-06.txt Pages : 57 Date : 2003-9-2 This memo defines an SMIv2 Management Information Base (MIB) for a device implementing NAT function [RFC2663]. Particular emphasis was placed on devices implementing traditional NAT function [RFC3022]. This MIB may be used for configuration as well as monitoring of a device capable of NAT function. The MIB may also be used for dynamic administration of resources on a NAT middlebox. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nat-natmib-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nat-natmib-06.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: <2003-9-2100217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nat-natmib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nat-natmib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-2100217.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Sep 2 13:25:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18316 for ; Tue, 2 Sep 2003 13:25:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEtu-0003jp-Jj for midcom-archive@odin.ietf.org; Tue, 02 Sep 2003 13:25:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82HP6VG014349 for midcom-archive@odin.ietf.org; Tue, 2 Sep 2003 13:25:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEtr-0003ii-P1; Tue, 02 Sep 2003 13:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEtW-0003hb-G9 for midcom@optimus.ietf.org; Tue, 02 Sep 2003 13:24:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18236 for ; Tue, 2 Sep 2003 13:24:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uEtU-00011L-00 for midcom@ietf.org; Tue, 02 Sep 2003 13:24:40 -0400 Received: from mx03.forces.gc.ca ([131.137.245.203]) by ietf-mx with esmtp (Exim 4.12) id 19uEtT-000117-00 for midcom@ietf.org; Tue, 02 Sep 2003 13:24:39 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 3CA4220660F for ; Tue, 2 Sep 2003 13:22:21 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19uEW1-00040Q-VT for ietf-announce-list@asgard.ietf.org; Tue, 02 Sep 2003 13:00:25 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19uEUv-0003vP-Nd for all-ietf@asgard.ietf.org; Tue, 02 Sep 2003 12:59:17 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14624; Tue, 2 Sep 2003 12:59:11 -0400 (EDT) Message-Id: <200309021659.MAA14624@ietf.org> To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Tue, 02 Sep 2003 12:59:11 -0400 Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+8842_51319818136775_248566099246" Subject: [midcom] I-D ACTION:draft-ietf-nat-natmib-06.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --MIMEStream=_0+8842_51319818136775_248566099246 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Definitions of Managed Objects for Network Address Translators (NAT) Author(s) : R. Raghunarayan, N. Pai, R. Rohit, C. Wang, P. Srisuresh Filename : draft-ietf-nat-natmib-06.txt Pages : 57 Date : 2003-9-2 This memo defines an SMIv2 Management Information Base (MIB) for a device implementing NAT function [RFC2663]. Particular emphasis was placed on devices implementing traditional NAT function [RFC3022]. This MIB may be used for configuration as well as monitoring of a device capable of NAT function. The MIB may also be used for dynamic administration of resources on a NAT middlebox. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nat-natmib-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nat-natmib-06.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. --MIMEStream=_0+8842_51319818136775_248566099246 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+114826_884610198511_945210581469" --MIMEStream=_1+114826_884610198511_945210581469 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-2100217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nat-natmib-06.txt --MIMEStream=_1+114826_884610198511_945210581469 Content-Type: Message/External-body; name="draft-ietf-nat-natmib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-2100217.I-D@ietf.org> --MIMEStream=_1+114826_884610198511_945210581469-- --MIMEStream=_0+8842_51319818136775_248566099246-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Sep 3 04:01:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12364 for ; Wed, 3 Sep 2003 04:01:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uSZe-0006vo-5c for midcom-archive@odin.ietf.org; Wed, 03 Sep 2003 04:01:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h838161s026616 for midcom-archive@odin.ietf.org; Wed, 3 Sep 2003 04:01:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uSZZ-0006uY-G1; Wed, 03 Sep 2003 04:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uSZT-0006tu-P5 for midcom@optimus.ietf.org; Wed, 03 Sep 2003 04:00:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12337 for ; Wed, 3 Sep 2003 04:00:49 -0400 (EDT) From: sbrim@cisco.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uSZQ-0000wE-00 for midcom@ietf.org; Wed, 03 Sep 2003 04:00:52 -0400 Received: from [218.6.192.153] (helo=INNET2) by ietf-mx with esmtp (Exim 4.12) id 19uSZ2-0000vo-00 for midcom@ietf.org; Wed, 03 Sep 2003 04:00:29 -0400 To: Date: Wed, 3 Sep 2003 16:06:41 +0800 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_01C018AE" Message-Id: Subject: [midcom] Re: Details Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_01C018AE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_01C018AE Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: movie0045.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_01C018AE-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Sep 3 15:14:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01586 for ; Wed, 3 Sep 2003 15:14:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ud4s-0000bh-Tu for midcom-archive@odin.ietf.org; Wed, 03 Sep 2003 15:14:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83JE2Jb002313 for midcom-archive@odin.ietf.org; Wed, 3 Sep 2003 15:14:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ud4q-0000ai-NG; Wed, 03 Sep 2003 15:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ud3w-0000Ze-T4 for midcom@optimus.ietf.org; Wed, 03 Sep 2003 15:13:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01347 for ; Wed, 3 Sep 2003 15:12:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ud3v-0007kG-00 for midcom@ietf.org; Wed, 03 Sep 2003 15:13:03 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19ud3a-0007ij-00 for midcom@ietf.org; Wed, 03 Sep 2003 15:12:42 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 03 Sep 2003 12:24:10 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h83JC9s6010674 for ; Wed, 3 Sep 2003 12:12:11 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-42.cisco.com [10.32.241.42]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ALQ78136; Wed, 3 Sep 2003 12:12:08 -0700 (PDT) Date: Wed, 3 Sep 2003 15:12:06 -0400 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Melinda Shore To: midcom@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <82278E42-DE42-11D7-BF27-000A95E35274@cisco.com> X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Subject: [midcom] Reminder: wg last call Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This is a reminder that we're in WG last call on the semantics document. Last call closes on Tuesday, 9 September. The URL for the document is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-04.txt Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Sep 3 22:07:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25794 for ; Wed, 3 Sep 2003 22:07:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ujWw-0001Al-BU for midcom-archive@odin.ietf.org; Wed, 03 Sep 2003 22:07:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8427PxZ004482 for midcom-archive@odin.ietf.org; Wed, 3 Sep 2003 22:07:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ujWs-00018h-0Y; Wed, 03 Sep 2003 22:07:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ujVv-00010z-RF for midcom@optimus.ietf.org; Wed, 03 Sep 2003 22:06:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25759 for ; Wed, 3 Sep 2003 22:06:16 -0400 (EDT) From: les.carter@newkinetics.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ujVs-0002uB-00 for midcom@ietf.org; Wed, 03 Sep 2003 22:06:20 -0400 Received: from sentinel.newkinetics.com ([66.92.184.212] helo=workhorse.newkinetics.com) by ietf-mx with esmtp (Exim 4.12) id 19ujVr-0002u8-00 for midcom@ietf.org; Wed, 03 Sep 2003 22:06:19 -0400 Received: from workhorse.newkinetics.com (localhost [127.0.0.1]) by workhorse.newkinetics.com (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id h842GqWx011044 for ; Wed, 3 Sep 2003 19:16:52 -0700 Received: (from carterl@localhost) by workhorse.newkinetics.com (8.12.2/8.12.2/Submit) id h842Gq7x011043; Wed, 3 Sep 2003 19:16:52 -0700 Date: Wed, 3 Sep 2003 19:16:52 -0700 Message-Id: <200309040216.h842Gq7x011043@workhorse.newkinetics.com> X-Authentication-Warning: workhorse.newkinetics.com: carterl set sender to les.carter@newkinetics.com using -f To: midcom@ietf.org X-Originating-IP: 10.1.1.111 X-Mailer: Usermin 1.000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bound1062641812" X-Virus-Scanned: by amavis-milter (http://amavis.org/) Subject: [midcom] STUN - NAT Discovery gap in logic? Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --bound1062641812 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit In Figure 2 of the STUN RFC 3489, I've got a question as to a possible outcome which may indicate a gap in the logic. The scenario is as follows: * - The first time Test 1 is executed (request sent to a1:p1) a valid response is returned, but the IP address is not the same. * - Test 2 (request sent to a1:p1) no response is obtained * - Here's the issue I feel. Test 1 is executed again (request sent to a2:p2) but does not get a response. The diagram and text that precedes it does not explain what should happen if no response is obtained. No response from the execution of Test 1 a second time to a2:p2 may fail for a number of reasons (misconfiguration of the server, firewall open for outbound STUN requests but no other ports, etc.), and I don't think it's a safe assumption that a response will be receieved. Given this situation what should be deduced from the NAT discovery process? I've noticed that some existing clients ignore the execution of Test 1 a second time and moves right through to Test 3. Should another NAT status or error be returned instead? Comments? L --bound1062641812-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Sep 4 02:14:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22318 for ; Thu, 4 Sep 2003 02:14:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19unNc-0002p1-84 for midcom-archive@odin.ietf.org; Thu, 04 Sep 2003 02:14:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h846E4Br010847 for midcom-archive@odin.ietf.org; Thu, 4 Sep 2003 02:14:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19unNZ-0002oF-TK; Thu, 04 Sep 2003 02:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19unNO-0002mf-Bm for midcom@optimus.ietf.org; Thu, 04 Sep 2003 02:13:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22220 for ; Thu, 4 Sep 2003 02:13:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19unNK-0003Gd-00 for midcom@ietf.org; Thu, 04 Sep 2003 02:13:46 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19unNK-0003Ft-00 for midcom@ietf.org; Thu, 04 Sep 2003 02:13:46 -0400 Received: from dynamicsoft.com ([63.113.46.28]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h846DHUg009128; Thu, 4 Sep 2003 02:13:20 -0400 (EDT) Message-ID: <3F56D7F9.8030304@dynamicsoft.com> Date: Thu, 04 Sep 2003 02:13:13 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: les.carter@newkinetics.com CC: midcom@ietf.org Subject: Re: [midcom] STUN - NAT Discovery gap in logic? References: <200309040216.h842Gq7x011043@workhorse.newkinetics.com> In-Reply-To: <200309040216.h842Gq7x011043@workhorse.newkinetics.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. les.carter@newkinetics.com wrote: > In Figure 2 of the STUN RFC 3489, I've got a question as to a > possible outcome which may indicate a gap in the logic. The > scenario is as follows: > > * - The first time Test 1 is executed (request sent to a1:p1) a > valid response is returned, but the IP address is not the same. > > * - Test 2 (request sent to a1:p1) no response is obtained > > * - Here's the issue I feel. Test 1 is executed again (request sent > to a2:p2) but does not get a response. The diagram and text that > precedes it does not explain what should happen if no response is > obtained. Normally one would be received. > > No response from the execution of Test 1 a second time to a2:p2 may > fail for a number of reasons (misconfiguration of the server, > firewall open for outbound STUN requests but no other ports, etc.), > and I don't think it's a safe assumption that a response will be > receieved. As you say, its hard to deduce a specific problem from a lack of a response. I will say that STUN is not meant to deduce firewall policies, but rather nat policies. If you have a firewall that blocks all ports but stun, this will not be detected, as it was not designed for that. I don't know why you would have such a configuration though, as it would defeat the purpose of anything stun would be used for. > > Given this situation what should be deduced from the NAT discovery > process? I've noticed that some existing clients ignore the > execution of Test 1 a second time and moves right through to Test > 3. Should another NAT status or error be returned instead? The execution of test 1 a second time is needed to differentiate between symmetric and port restricted, so I dont know why it would be skipped. I feel I should make a higher level point though. We recognized when writing STUN that the nat type detection algorithm, being a "black box test", could never be definitive, and there are a lot of assumptions that go into the test - principally, the characterization of nat behaviors. These are all discussed in the IAB considerations section, which is worth reading. A better approach, rather than to try to detect the type of nat you are behind, is to bilaterally test for connectivity with your peer using STUN. THis concept, called ICE, is discussed in detail in: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-01.txt WHen a client uses ICE, it no longer needs to perform the nat type check described in Section 10.1 of STUN. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Sep 4 03:03:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25748 for ; Thu, 4 Sep 2003 03:03:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uo9L-0006Rp-W0 for midcom-archive@odin.ietf.org; Thu, 04 Sep 2003 03:03:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8473NEf024785 for midcom-archive@odin.ietf.org; Thu, 4 Sep 2003 03:03:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uo9E-0006Qs-6X; Thu, 04 Sep 2003 03:03:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uo8A-0006Pl-7X for midcom@optimus.ietf.org; Thu, 04 Sep 2003 03:02:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25717 for ; Thu, 4 Sep 2003 03:02:02 -0400 (EDT) From: les.carter@newkinetics.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uo85-0005Br-00 for midcom@ietf.org; Thu, 04 Sep 2003 03:02:05 -0400 Received: from sentinel.newkinetics.com ([66.92.184.212] helo=workhorse.newkinetics.com) by ietf-mx with esmtp (Exim 4.12) id 19uo84-0005Bb-00 for midcom@ietf.org; Thu, 04 Sep 2003 03:02:05 -0400 Received: from workhorse.newkinetics.com (localhost [127.0.0.1]) by workhorse.newkinetics.com (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id h847CdBU007592; Thu, 4 Sep 2003 00:12:39 -0700 Received: (from carterl@localhost) by workhorse.newkinetics.com (8.12.2/8.12.2/Submit) id h847Cdc8007591; Thu, 4 Sep 2003 00:12:39 -0700 Date: Thu, 4 Sep 2003 00:12:39 -0700 Message-Id: <200309040712.h847Cdc8007591@workhorse.newkinetics.com> X-Authentication-Warning: workhorse.newkinetics.com: carterl set sender to les.carter@newkinetics.com using -f Subject: Re: [midcom] STUN - NAT Discovery gap in logic? To: Jonathan Rosenberg Cc: midcom@ietf.org X-Originating-IP: 10.1.1.111 X-Mailer: Usermin 1.000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bound1062659559" X-Virus-Scanned: by amavis-milter (http://amavis.org/) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --bound1062659559 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Comments/queries inlined (previous inserts kept for context): > > * - The first time Test 1 is executed (request sent to a1:p1) a > > valid response is returned, but the IP address is not the same. > > > > * - Test 2 (request sent to a1:p1) no response is obtained > > > > * - Here's the issue I feel. Test 1 is executed again (request sent > > to a2:p2) but does not get a response. The diagram and text that > > precedes it does not explain what should happen if no response is > > obtained. > > Normally one would be received. I would have thought this would have been the case too, however while testing against some well known publically available STUN servers connections were refused to the CHANGED-ADDRESS details. > > No response from the execution of Test 1 a second time to a2:p2 may > > fail for a number of reasons (misconfiguration of the server, > > firewall open for outbound STUN requests but no other ports, etc.), > > and I don't think it's a safe assumption that a response will be > > receieved. > > As you say, its hard to deduce a specific problem from a lack of a > response. I will say that STUN is not meant to deduce firewall > policies, but rather nat policies. If you have a firewall that blocks > all ports but stun, this will not be detected, as it was not designed > for that. I don't know why you would have such a configuration though, > as it would defeat the purpose of anything stun would be used for. This isn't a far fetched scenario, it could be quite conceivable that an enterprise could well leave the well known port for STUN (3478) open to traffic for the purpose of figuring out the NAT'd IP address from a bind response in test 1, but because the CHANGED-ADDRESS port number is arbitrary it effectively requires all outbound UDP traffic to not be restricted. Some paranoid network admins don't allow such configurations. > > Given this situation what should be deduced from the NAT discovery > > process? I've noticed that some existing clients ignore the > > execution of Test 1 a second time and moves right through to Test > > 3. Should another NAT status or error be returned instead? > > The execution of test 1 a second time is needed to differentiate > between symmetric and port restricted, so I dont know why it would be > skipped. It's not that it's skipped as such, it's just that if the logic is followed through to the letter and no response is obtained from the 2nd Test 1, to make a decision of whether or not the IP address was local or not wouldn't be valid. I think this greyness could be interpreted different ways by different people and it's this kind of point that the specification should resolve definitively (ie. state that this should be an error, or that Test 3 should be executed) so that everyone is reading off of the same song sheet. Not doing so could lead to different vendors of STUN clients interpreting results differently and this would be detrimental to the purpose of STUN in the first place. Clear resolution as to what happens should be catered in the RFC to cover a likelyhood like this, belief that things "should" work isn't in experience good enough in real life situations. Thanks for your response Jonathan, it was much appreciated. Les --bound1062659559-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Sep 4 03:57:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29307 for ; Thu, 4 Sep 2003 03:57:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uozU-0000p7-To for midcom-archive@odin.ietf.org; Thu, 04 Sep 2003 03:57:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h847vEGM003137 for midcom-archive@odin.ietf.org; Thu, 4 Sep 2003 03:57:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uozH-0000ny-7C; Thu, 04 Sep 2003 03:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uoz5-0000nb-1I for midcom@optimus.ietf.org; Thu, 04 Sep 2003 03:56:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29257 for ; Thu, 4 Sep 2003 03:56:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uoz2-0007WG-00 for midcom@ietf.org; Thu, 04 Sep 2003 03:56:48 -0400 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 19uoz1-0007Td-00 for midcom@ietf.org; Thu, 04 Sep 2003 03:56:47 -0400 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 10E0C48DCA; Thu, 4 Sep 2003 09:56:18 +0200 (CEST) Received: from james (unknown [212.201.47.15]) by merkur.iu-bremen.de (Postfix) with ESMTP id 74991484FE; Thu, 4 Sep 2003 09:56:17 +0200 (CEST) Received: by james (Postfix, from userid 1000) id 1AFC38513; Thu, 4 Sep 2003 09:56:17 +0200 (CEST) Date: Thu, 4 Sep 2003 09:56:16 +0200 From: Juergen Schoenwaelder To: Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] Reminder: wg last call Message-ID: <20030904075616.GA695@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Melinda Shore , midcom@ietf.org References: <82278E42-DE42-11D7-BF27-000A95E35274@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82278E42-DE42-11D7-BF27-000A95E35274@cisco.com> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Wed, Sep 03, 2003 at 03:12:06PM -0400, Melinda Shore wrote: > This is a reminder that we're in WG last call on the semantics > document. Last call closes on Tuesday, 9 September. The URL > for the document is: > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-04.txt I will once more bring up a comment which I did already made when I reviewed the previous revision of the document and where I did not see much of a discussion. I am still concerned about making all transactions that allow to retrieve what is actually installed on a device optional. For debugging and development purposes, I believe it is essential to be able to retrieve the installed policies and groups. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Sep 4 22:48:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13005 for ; Thu, 4 Sep 2003 22:48:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v6dw-0004Oy-8N for midcom-archive@odin.ietf.org; Thu, 04 Sep 2003 22:48:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h852mCKl016916 for midcom-archive@odin.ietf.org; Thu, 4 Sep 2003 22:48:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v6dp-0004LN-Q8; Thu, 04 Sep 2003 22:48:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v6di-0004JQ-Hr for midcom@optimus.ietf.org; Thu, 04 Sep 2003 22:48:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12937 for ; Thu, 4 Sep 2003 22:47:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v6df-0005jm-00 for midcom@ietf.org; Thu, 04 Sep 2003 22:47:55 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19v6dc-0005iw-00 for midcom@ietf.org; Thu, 04 Sep 2003 22:47:54 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h852lHAw019104; Thu, 4 Sep 2003 19:47:17 -0700 (PDT) Received: from [10.0.1.2] (sjc-vpn2-814.cisco.com [10.21.115.46]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHU31785; Thu, 4 Sep 2003 19:47:16 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 04 Sep 2003 19:45:47 -0700 Subject: Re: [midcom] STUN - NAT Discovery gap in logic? From: Cullen Jennings To: , Jonathan Rosenberg CC: Midcom Message-ID: In-Reply-To: <200309040712.h847Cdc8007591@workhorse.newkinetics.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 9/4/03 12:12 AM, "les.carter@newkinetics.com" < > > I would have thought this would have been the case too, however while testing > against some well known publically available STUN servers connections were > refused to the CHANGED-ADDRESS details. > Some of the early STUN implementation ran across two servers - operational experience showed this was a bad mistake and I have mentioned it before on the list. The two addresses need to be fate shared or STUN can give the wrong result. I highly recommend all implementers run with two IP address on the same NIC card on the same Ethernet cable. That way if the cable gets pulled or something else happens, hopefully neither will be reachable. The server at stun.vovida.org is in an embarrassing state of disarray and I apologize for the poor operation of it - it's been on my todo list to fix. Cullen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sat Sep 6 17:17:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05752 for ; Sat, 6 Sep 2003 17:17:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vkQj-0002OD-Ff for midcom-archive@odin.ietf.org; Sat, 06 Sep 2003 17:17:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h86LHDYc009181 for midcom-archive@odin.ietf.org; Sat, 6 Sep 2003 17:17:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vkQc-0002L9-65; Sat, 06 Sep 2003 17:17:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vkQB-0002E6-NV for midcom@optimus.ietf.org; Sat, 06 Sep 2003 17:16:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05543 for ; Sat, 6 Sep 2003 17:16:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vkQ8-0001lH-00 for midcom@ietf.org; Sat, 06 Sep 2003 17:16:36 -0400 Received: from web40401.mail.yahoo.com ([66.218.78.98]) by ietf-mx with smtp (Exim 4.12) id 19vkPq-0001fl-00 for midcom@ietf.org; Sat, 06 Sep 2003 17:16:18 -0400 Message-ID: <20030906211547.79199.qmail@web40401.mail.yahoo.com> Received: from [66.224.113.194] by web40401.mail.yahoo.com via HTTP; Sat, 06 Sep 2003 14:15:47 PDT Date: Sat, 6 Sep 2003 14:15:47 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Reminder: wg last call To: midcom@ietf.org Cc: srisuresh@yahoo.com, stiemerling@ccrle.nec.de, quittek@ccrle.nec.de, taylor@nortelnetworks.com In-Reply-To: <82278E42-DE42-11D7-BF27-000A95E35274@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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Below is text of the e-mail (a little revised) I sent to the authors earlier. I am including the text for wider audience. Below are my outstanding comments on the draft. 1. For a NAT middlebox, I believe, the semantics ought to cover the following transactions. My comments assume the following. A. NAT is configured on a per-interface basis. As such, the Midcom/NAT transactions would be specified on a per-interface basis. B. End-point below is to be refered as for a PortBind. End-point for an address Bind will be . The IP address can be V4 or V6. C. The transactions specified below can be applicable to one or more end-points. This will include address ranges, address wild-carding, port ranges, and port wild-carding. SetMapOwner [Full | Partial] [] - SetMapowner may be used by an agent to claim ownership on a complete NAT map entry or a portion of the entry. AgentId will be set as the owner of the entire map entry or portion thereof. (CreateBind | CreatePortBind) - Agent specifies all the requisite Parameters for Bind(s) or PortBind(s). Agent requests middlebox to create a BIND and respond back with an assigned BindId. Middlebox to validate the authorization prior to responding. (RequestCreateBind | RequestPortCreateBind) [Oddity option] - Agent requests the Middlebox to create BIND(s) for the given End-point, optionally with an Oddity requirement. Middlebox to validate the authorization, prior to assgining a BIND and a BindId and returning the response. CreateOutboundSession | | - Agent specifies all the requisite Parameters for an outbound session. Agent requests middlebox to create a session as specified and respond back with an assigned BindId. The session may have one or two end-point translations. The session may be derived directly from the address map (or) from associated Bind-IDs. Middlebox to validate the authorization prior to responding. Note, the session tuple may have wild-card elements. RequestCreateOutboundSession | | - Agent requests the Middlebox to create an outbound session for the given session tuple, using one or more map entries and/or end-point BINDs. Agent to validate he authorization prior to responding back with a new session and session-id. As before, the session tuple may have wild-card elements. CreateInboundSession, RequestCreateInboundSession - Similar to the outbound counterparts. ModifyBindParameters [] [MaximumIdletime>] [] - These parameters may be specified either at Bind creation time or later. ModifySessionParameters [] [MaximumIdletime>] [] - These parameters may be specified either at session creation time or later. Note, session here refers to the NAT data sessions, not the Midcom agent session. In particular, I would like to mention the notion of three resources a NAT middlebox and midcom agent need to be cognizant of - Address map entries, Binds and sessions. These resources may be a) created by the agent, b) created by the NAT middlebox, or c) paramaters modified by the agent. 2. The notion of PRR is incomplete without the context of the entire address map entry. The reservation may not be specific to address/address-port alone. My view of this is simply that PRR is just another notion of ownership claim. it just happens to be in relation to an address map entry. 3. When you combine the notion of PRR wth PER, the state transition diagram in section 2.3.13 woudl be simplified, with the proviso that there would be three types of policy rules (address map entries, binds and sessions). 4. I agree with your notion of Session establishment and session termination transactions. 5. I believe, the group Ids an agent would use during the lifetime of a Midcom session should be specified by the agent - either at the midcom session establishment time or afterwards whild the midcom session is alive. Given that group-Ids are specific to an agent, it shoudl be agent's responsibility to assign group IDs, not that of the middlebox's. Further, given that there are 3 different types of resources (map entries, Binds and sessions), there shoudl be three different sets of group-Ids, one set for each resource type. Middlebox will assign a default groupId of 0 to all entities that are not assigned a groupId by the agent. regards, suresh --- Melinda Shore wrote: > This is a reminder that we're in WG last call on the semantics > document. Last call closes on Tuesday, 9 September. The URL > for the document is: > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-04.txt > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Sep 8 22:37:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02625 for ; Mon, 8 Sep 2003 22:37:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wYNR-0007op-Vs for midcom-archive@odin.ietf.org; Mon, 08 Sep 2003 22:37:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h892b9N4030030 for midcom-archive@odin.ietf.org; Mon, 8 Sep 2003 22:37:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wYNJ-0007lT-ID; Mon, 08 Sep 2003 22:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wYM5-0007fJ-7A for midcom@optimus.ietf.org; Mon, 08 Sep 2003 22:36:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02566 for ; Mon, 8 Sep 2003 22:35:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wYLw-0004Tq-00 for midcom@ietf.org; Mon, 08 Sep 2003 22:35:36 -0400 Received: from 67.105.118.114.ptr.us.xo.net ([67.105.118.114] helo=mail.kmerl.com) by ietf-mx with esmtp (Exim 4.12) id 19wYLm-0004SW-00 for midcom@ietf.org; Mon, 08 Sep 2003 22:35:26 -0400 content-class: urn:content-classes:message Subject: RE: [midcom] STUN - NAT Discovery gap in logic? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Sep 2003 19:28:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: Thread-Topic: [midcom] STUN - NAT Discovery gap in logic? Thread-Index: AcNysqjlBDapwzxOTJyIJqlVyLPhnADpbmvA From: "Yutaka Takeda" To: , "Jonathan Rosenberg" Cc: Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I have experienced the same situation with a router, not receiving a response in the second Test 1. I treated it as "UDP BLOCKED", however, the situation is a little worse than that. The router we have tested with STUN has a firewall integrated. The router does not forward responses at the second Test 1 from a STUN server to a STUN client though the client has sent to a packet to a transport address from which the responses are sent. The reason I found later on was that in Test 2 before the second Test 1=20 the firewall that received multiple packets from unknown address=20 treated the packets as an attack and dropped all the subsequent=20 packets from the same address. This is why the response in the=20 second Test1 did not arrive. To make matters worse, any packets from the address are ignored, and in order to reset this blockage with the router, I had to ask a network admin to do so... (manual reset) I would like to come up with a solution to this, however, so far I have nothing but just treating this case as being resulted in=20 "UDP BLOCKED". Any opinions or suggestions to this will be appreciated.=20 Yutaka > -----Original Message----- > From: les.carter@newkinetics.com [mailto:les.carter@newkinetics.com] > Sent: Thursday, September 04, 2003 12:13 AM > To: Jonathan Rosenberg > Cc: midcom@ietf.org > Subject: Re: [midcom] STUN - NAT Discovery gap in logic? >=20 >=20 > Comments/queries inlined (previous inserts kept for context): >=20 > > > * - The first time Test 1 is executed (request sent to a1:p1) a > > > valid response is returned, but the IP address is not the same. > > >=20 > > > * - Test 2 (request sent to a1:p1) no response is obtained > > >=20 > > > * - Here's the issue I feel. Test 1 is executed again=20 > (request sent > > > to a2:p2) but does not get a response. The diagram and text that > > > precedes it does not explain what should happen if no response is > > > obtained. > >=20 > > Normally one would be received. > =20 > I would have thought this would have been the case too,=20 > however while testing against some well known publically=20 > available STUN servers connections were refused to the=20 > CHANGED-ADDRESS details. >=20 >=20 > > > No response from the execution of Test 1 a second time to=20 > a2:p2 may > > > fail for a number of reasons (misconfiguration of the server, > > > firewall open for outbound STUN requests but no other=20 > ports, etc.), > > > and I don't think it's a safe assumption that a response will be > > > receieved. > >=20 > > As you say, its hard to deduce a specific problem from a lack of a=20 > > response. I will say that STUN is not meant to deduce firewall=20 > > policies, but rather nat policies. If you have a firewall=20 > that blocks=20 > > all ports but stun, this will not be detected, as it was=20 > not designed=20 > > for that. I don't know why you would have such a=20 > configuration though, > > as it would defeat the purpose of anything stun would be used for. >=20 > This isn't a far fetched scenario, it could be quite=20 > conceivable that an enterprise could well leave the well=20 > known port for STUN (3478) open to traffic for the purpose of=20 > figuring out the NAT'd IP address from a bind response in=20 > test 1, but because the CHANGED-ADDRESS port number is=20 > arbitrary it effectively requires all outbound UDP traffic to=20 > not be restricted. Some paranoid network admins don't allow=20 > such configurations.=20 >=20 >=20 > > > Given this situation what should be deduced from the NAT discovery > > > process? I've noticed that some existing clients ignore the > > > execution of Test 1 a second time and moves right through to Test > > > 3. Should another NAT status or error be returned instead? > >=20 > > The execution of test 1 a second time is needed to differentiate=20 > > between symmetric and port restricted, so I dont know why=20 > it would be=20 > > skipped. >=20 > It's not that it's skipped as such, it's just that if the=20 > logic is followed through to the letter and no response is=20 > obtained from the 2nd Test 1, to make a decision of whether=20 > or not the IP address was local or not wouldn't be valid. I=20 > think this greyness could be interpreted different ways by=20 > different people and it's this kind of point that the=20 > specification should resolve definitively (ie. state that=20 > this should be an error, or that Test 3 should be executed)=20 > so that everyone is reading off of the same song sheet. Not=20 > doing so could lead to different vendors of STUN clients=20 > interpreting results differently and this would be=20 > detrimental to the purpose of STUN in the first place. Clear=20 > resolution as to what happens should be catered in the RFC to=20 > cover a likelyhood like this, belief that things "should"=20 > work isn't in experience good enough in real life situations. >=20 > Thanks for your response Jonathan, it was much appreciated. >=20 > Les >=20 >=20 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Sep 8 23:05:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03536 for ; Mon, 8 Sep 2003 23:05:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wYoW-0000GH-IB for midcom-archive@odin.ietf.org; Mon, 08 Sep 2003 23:05:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89358re000866 for midcom-archive@odin.ietf.org; Mon, 8 Sep 2003 23:05:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wYoP-0000DV-HK; Mon, 08 Sep 2003 23:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wYoB-0000D5-OI for midcom@optimus.ietf.org; Mon, 08 Sep 2003 23:04:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03502 for ; Mon, 8 Sep 2003 23:04:38 -0400 (EDT) From: les.carter@newkinetics.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wYo7-0004kp-00 for midcom@ietf.org; Mon, 08 Sep 2003 23:04:44 -0400 Received: from sentinel.newkinetics.com ([66.92.184.212] helo=workhorse.newkinetics.com) by ietf-mx with esmtp (Exim 4.12) id 19wYnw-0004iu-00 for midcom@ietf.org; Mon, 08 Sep 2003 23:04:32 -0400 Received: from workhorse.newkinetics.com (localhost [127.0.0.1]) by workhorse.newkinetics.com (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id h893CNgh030869; Mon, 8 Sep 2003 20:12:23 -0700 Received: (from carterl@localhost) by workhorse.newkinetics.com (8.12.2/8.12.2/Submit) id h893CN8T030868; Mon, 8 Sep 2003 20:12:23 -0700 Date: Mon, 8 Sep 2003 20:12:23 -0700 Message-Id: <200309090312.h893CN8T030868@workhorse.newkinetics.com> X-Authentication-Warning: workhorse.newkinetics.com: carterl set sender to les.carter@newkinetics.com using -f Subject: RE: [midcom] STUN - NAT Discovery gap in logic? To: "Yutaka Takeda" Cc: "Jonathan Rosenberg" , X-Originating-IP: 10.1.1.118 X-Mailer: Usermin 1.000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bound1063077142" X-Virus-Scanned: by amavis-milter (http://amavis.org/) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --bound1063077142 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit You hit the exact problem I was describing Yutaka with the words "I treated it as". Someone else could intepret the situation differently, for example as an erroneous state. I propose that the logic for NAT discovery be altered so that it shows: +--------+ | Test | | I | +--------+ | | V /\ /\ N / \ Y / \ Y +--------+ UDP <-------/Resp\--------->/ IP \------------->| Test | Blocked \ ? / \Same/ | II | \ / \? / +--------+ \/ \/ | | N | | V V /\ +--------+ Sym. N / \ | Test | UDP <---/Resp\ | II | Firewall \ ? / +--------+ \ / | \/ V |Y /\ /\ | Selective N / \ +--------+ N / \ V Outbound <-- /Resp\<-----| Test |<--- /Resp\ Open /Service NAT \ ? / | I | \ ? / Internet \ / +--------+ \ / \/ \/ |Y |Y | | | V V Full /\ Cone Symmetric N / \ NAT <--- / IP \ \Same/ \? / \/ |Y | V /\ +--------+ / \ Y | Test |------>/Resp\---->Restricted | III | \ ? / +--------+ \ / \/ |N | Port +------>Restricted Whereby if the 2nd execution of Test I using the changed address fails to receive a response it is indicated to be of type "Selective Outbound/Service NAT" indicating that the NAT firewall used for outbound communication from the client has selective port filtering, or that the machine running the STUN server has chosen not to listen to request on a CHANGED-ADDRESS. This maybe because the administrator of the STUN server may only desire the IP address discovery portion of STUN to be used and not the NAT discovery portion. If the latter is the case, there should be something in the RFC that indicates that the STUN server will return the same IP address/port as the original request was made if it does not intend to do NAT discovery but still send out a CHANGE-ADDRESS attribute (ie. a1/p1=a2/p2). L "Yutaka Takeda" wrote .. > > I have experienced the same situation with a router, not receiving a > response in the second Test 1. I treated it as "UDP BLOCKED", > however, the situation is a little worse than that. > > The router we have tested with STUN has a firewall integrated. The > router does not forward responses at the second Test 1 from a STUN > server to a STUN client though the client has sent to a packet to a > transport address from which the responses are sent. > > The reason I found later on was that in Test 2 before the second Test 1 > the firewall that received multiple packets from unknown address > treated the packets as an attack and dropped all the subsequent > packets from the same address. This is why the response in the > second Test1 did not arrive. To make matters worse, any packets > from the address are ignored, and in order to reset this blockage > with the router, I had to ask a network admin to do so... (manual > reset) > > I would like to come up with a solution to this, however, so far I have > nothing but just treating this case as being resulted in > "UDP BLOCKED". > > Any opinions or suggestions to this will be appreciated. > Yutaka > > > > -----Original Message----- > > From: les.carter@newkinetics.com [mailto:les.carter@newkinetics.com] > > Sent: Thursday, September 04, 2003 12:13 AM > > To: Jonathan Rosenberg > > Cc: midcom@ietf.org > > Subject: Re: [midcom] STUN - NAT Discovery gap in logic? > > > > > > Comments/queries inlined (previous inserts kept for context): > > > > > > * - The first time Test 1 is executed (request sent to a1:p1) a > > > > valid response is returned, but the IP address is not the same. > > > > > > > > * - Test 2 (request sent to a1:p1) no response is obtained > > > > > > > > * - Here's the issue I feel. Test 1 is executed again > > (request sent > > > > to a2:p2) but does not get a response. The diagram and text that > > > > precedes it does not explain what should happen if no response is > > > > obtained. > > > > > > Normally one would be received. > > > > I would have thought this would have been the case too, > > however while testing against some well known publically > > available STUN servers connections were refused to the > > CHANGED-ADDRESS details. > > > > > > > > No response from the execution of Test 1 a second time to > > a2:p2 may > > > > fail for a number of reasons (misconfiguration of the server, > > > > firewall open for outbound STUN requests but no other > > ports, etc.), > > > > and I don't think it's a safe assumption that a response will be > > > > receieved. > > > > > > As you say, its hard to deduce a specific problem from a lack of a > > > response. I will say that STUN is not meant to deduce firewall > > > policies, but rather nat policies. If you have a firewall > > that blocks > > > all ports but stun, this will not be detected, as it was > > not designed > > > for that. I don't know why you would have such a > > configuration though, > > > as it would defeat the purpose of anything stun would be used for. > > > > This isn't a far fetched scenario, it could be quite > > conceivable that an enterprise could well leave the well > > known port for STUN (3478) open to traffic for the purpose of > > figuring out the NAT'd IP address from a bind response in > > test 1, but because the CHANGED-ADDRESS port number is > > arbitrary it effectively requires all outbound UDP traffic to > > not be restricted. Some paranoid network admins don't allow > > such configurations. > > > > > > > > Given this situation what should be deduced from the NAT discovery > > > > process? I've noticed that some existing clients ignore the > > > > execution of Test 1 a second time and moves right through to Test > > > > 3. Should another NAT status or error be returned instead? > > > > > > The execution of test 1 a second time is needed to differentiate > > > between symmetric and port restricted, so I dont know why > > it would be > > > skipped. > > > > It's not that it's skipped as such, it's just that if the > > logic is followed through to the letter and no response is > > obtained from the 2nd Test 1, to make a decision of whether > > or not the IP address was local or not wouldn't be valid. I > > think this greyness could be interpreted different ways by > > different people and it's this kind of point that the > > specification should resolve definitively (ie. state that > > this should be an error, or that Test 3 should be executed) > > so that everyone is reading off of the same song sheet. Not > > doing so could lead to different vendors of STUN clients > > interpreting results differently and this would be > > detrimental to the purpose of STUN in the first place. Clear > > resolution as to what happens should be catered in the RFC to > > cover a likelyhood like this, belief that things "should" > > work isn't in experience good enough in real life situations. > > > > Thanks for your response Jonathan, it was much appreciated. > > > > Les > > > > --bound1063077142-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Sep 9 10:51:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14494 for ; Tue, 9 Sep 2003 10:51:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjpe-0001uc-CD for midcom-archive@odin.ietf.org; Tue, 09 Sep 2003 10:51:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89Ep23c007346 for midcom-archive@odin.ietf.org; Tue, 9 Sep 2003 10:51:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjpc-0001to-Ib; Tue, 09 Sep 2003 10:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjok-0001rX-IC for midcom@optimus.ietf.org; Tue, 09 Sep 2003 10:50:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14381 for ; Tue, 9 Sep 2003 10:49:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wjoi-0004kD-00 for midcom@ietf.org; Tue, 09 Sep 2003 10:50:04 -0400 Received: from web13104.mail.yahoo.com ([216.136.174.149]) by ietf-mx with smtp (Exim 4.12) id 19wjoh-0004kA-00 for midcom@ietf.org; Tue, 09 Sep 2003 10:50:03 -0400 Message-ID: <20030909145002.32784.qmail@web13104.mail.yahoo.com> Received: from [200.165.219.216] by web13104.mail.yahoo.com via HTTP; Tue, 09 Sep 2003 07:50:02 PDT Date: Tue, 9 Sep 2003 07:50:02 -0700 (PDT) From: Daniel Fonseca Subject: Re: [midcom] Reminder: wg last call To: midcom@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Dear WG members, I am in the final semester of Computer Science, and the subject of my undergraduate qualifying project will be the kind of service this WG is attempting to offer, with more focus on midcom itself. I have read the midcom RFCs and drafts written so far, the mailing list messages, and part of the UPnP documentation, but I have found very little more about that kind of firewall/NAT/"middlebox" configuration on the internet. There are a few presentations and proprietary solutions, yet none of them discuss the subject nearly as deep, or suggest a solution with the required robustness and/or flexibility. If you know any other source of information regarding this subject, either papers, web sites, presentations or documentation of any sort, I would appreciate it if you would send it to me. I have prepared my own set of comments on the latest revision of the semantics, they are copied below. Although most are type/grammar misspellings, maybe it can be of some use to you. Thanks in advance, Daniel Fonseca dfonseca@ufrj.br ------------------------- ------------------------- Page 3, "... and the (4) reply and notification messages send from the middlebox to the agent ...". Should be "messages sent from the middlebox", right? Page 7, "Convenience transaction simplify MIDCOM sessions ...". Should be "transactions". Page 10, "... configuration of authorization at the middelbox is ...". Should be "middlebox". Page 10, "- internal IP address wildcard support - external IP address wildcard support" (I believe this has been mentioned recently in the list) It is very common for middlebox-ish devices to have more than two interfaces. How is midcom going to handle that? Shouldn't there be an interface-id? This involves many other sections in the text. Page 11, section 2.1.8: "A mandatory request transaction must be offered to each of the authenticated agents." I think this paragraph gets confusing when it approaches the difference between mandatory-optional and (un)authorized transactions. Maybe not all mandatory transactions should be offered to all agents, and each agent could be offered only the transactions it is authorized to perform. Is that off scope? Page 12, "All transaction are transmitted within this MIDCOM session." Should be "All transactions are ...", or even "Every transaction must be ...". Page 16, Figure 2. Forgive me if I have skipped or forgotten something, but with the info up to this point in the text, I had no clue how "mc=0" relates to a successful middlebox challenge. The idea is understood, but why is mc supposed to be 0, not "OK" or "success"? Page 18, "Each policy rule is member of exactly one policy rule group." Although this seems to be a deliberate decision, but I would like to know why a rule can't be on more than one group, for it could be helpful. Ease of implementation? Page 20, "... address tuple A0 specifies a communication endpoint of a devices within ..." Should be either "of all devices", "of a device", or even "of devices". Page 21, "For the transport protcols TCP and UDP ..." Should be "protocols". Page 21, "The MIDCOM semantics defined in this document define the handling of IPv4 and IPv6 as network protocols. For the transport protcols TCP and UDP over either IPv4 or IPv6 are supported." I believe readability would improve if it were rephrased as "The MIDCOM semantics defined in this document define the handling of IPv4 and IPv6 as network protocols, and of TCP and UDP (over IPv4 or IPv6) as transport protocols." Page 21, "The value of the transport protocol parameter can have one of the following values: 'TCP', 'UDP', 'ANY'." The value can have a value? Just for clarification, this could be rephrased as "The value of the transport protocol parameter can be either 'TCP', 'UDP' or 'ANY'." Page 22, the last paragraph of section 2.3.6. That's a verbose description of what a port range means. Assuming the reader is familiar with the normative reference documents, I think that entire paragraph is unnecessary. Page 23, "- mode: the requested NAT mode of the middlebox. Allowed values are 'traditional' or 'twice'." How about changing the name of this paramenter to "service", or something more flexible than "mode". I think that would maintain current meaning, and allow other types of services (maybe firewall could have its own service). Page 25, "The middelbox always reserves ..." Should be "middlebox". Page 28, "This transactions can be used ..." Should be "This transaction". Page 32, "A failure reply implies that the lifetime of the policy rule remains unchanged. A success reply is generated by the middlebox, if the lifetime of the policy rule was changed in any way." I know this should hardly ever happen, but the case of a RLC attempting to set the new lifetime to the exact current lifetime value was not covered. That should be a success, right? How about rephrasing the first sentence above to "A failure reply implies that the new lifetime was not accepted, and the policy rule remains unchanged." ? Page 34, "- port range: the number of consecutive ports numbers, see Section 2.3.5." Should be "consecutive port numbers". Page 43, "This multiple fine-grained transactions must further met the atomicity requirement stated in section 2.1.3." Should be "These multiple fine-grained transactions must further meet the atomicity ..." __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Sep 10 11:36:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04824 for ; Wed, 10 Sep 2003 11:36:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x70k-0000fU-Ds for midcom-archive@odin.ietf.org; Wed, 10 Sep 2003 11:36:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8AFa2xk002544 for midcom-archive@odin.ietf.org; Wed, 10 Sep 2003 11:36:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x70i-0000eV-Ra; Wed, 10 Sep 2003 11:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x70d-0000eC-8E for midcom@optimus.ietf.org; Wed, 10 Sep 2003 11:35:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04756 for ; Wed, 10 Sep 2003 11:35:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x70c-0004ro-00 for midcom@ietf.org; Wed, 10 Sep 2003 11:35:54 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19x70b-0004rG-00 for midcom@ietf.org; Wed, 10 Sep 2003 11:35:53 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8AFZMdP027677 for ; Wed, 10 Sep 2003 08:35:22 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-43.cisco.com [10.32.241.43]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ALY29735; Wed, 10 Sep 2003 08:35:20 -0700 (PDT) Date: Wed, 10 Sep 2003 11:35:19 -0400 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Melinda Shore To: midcom@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <624FAD60-E3A4-11D7-A8AC-000A95E35274@cisco.com> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [midcom] Going once, going twice ... Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Last call on the midcom semantics document is closed, with several comments received from Juergen Schoenwalder, Suresh, and Daniel Fonseca. If you sent comments and I didn't mention you, please let me know. Many thanks to those who read the draft and provided feedback. We will update the mailing list on resulting changes to the document as they're incorporated. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Sep 11 02:16:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12623 for ; Thu, 11 Sep 2003 02:16:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xKkZ-0007YA-AW for midcom-archive@odin.ietf.org; Thu, 11 Sep 2003 02:16:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8B6GFQo029023 for midcom-archive@odin.ietf.org; Thu, 11 Sep 2003 02:16:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xKkL-0007WA-Tn; Thu, 11 Sep 2003 02:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xKk1-0007Sl-0z for midcom@optimus.ietf.org; Thu, 11 Sep 2003 02:15:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12521 for ; Thu, 11 Sep 2003 02:15:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xKjx-0005Dn-00 for midcom@ietf.org; Thu, 11 Sep 2003 02:15:37 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19xKjx-0005BA-00 for midcom@ietf.org; Thu, 11 Sep 2003 02:15:37 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 10 Sep 2003 23:28:22 -0700 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h8B6F1S4008244; Wed, 10 Sep 2003 23:15:01 -0700 (PDT) Received: from [10.0.1.2] (sjc-vpn1-408.cisco.com [10.21.97.152]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHZ61267; Wed, 10 Sep 2003 23:15:00 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 10 Sep 2003 23:15:01 -0700 Subject: Re: [midcom] STUN - NAT Discovery gap in logic? From: Cullen Jennings To: Yutaka Takeda , CC: Midcom , Jonathan Rosenberg Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit You might want to put a little bit of time (like 10 ms) between sending each of your packets. This tends to prevent the problem of the NAT thinking it is under a DOS attack. On 9/8/03 19:28, "Yutaka Takeda" wrote: > > I have experienced the same situation with a router, not receiving a > response in the second Test 1. I treated it as "UDP BLOCKED", > however, the situation is a little worse than that. > > The router we have tested with STUN has a firewall integrated. The > router does not forward responses at the second Test 1 from a STUN > server to a STUN client though the client has sent to a packet to a > transport address from which the responses are sent. > > The reason I found later on was that in Test 2 before the second Test 1 > the firewall that received multiple packets from unknown address > treated the packets as an attack and dropped all the subsequent > packets from the same address. This is why the response in the > second Test1 did not arrive. To make matters worse, any packets > from the address are ignored, and in order to reset this blockage > with the router, I had to ask a network admin to do so... (manual > reset) > > I would like to come up with a solution to this, however, so far I have > nothing but just treating this case as being resulted in > "UDP BLOCKED". > > Any opinions or suggestions to this will be appreciated. > Yutaka > > >> -----Original Message----- >> From: les.carter@newkinetics.com [mailto:les.carter@newkinetics.com] >> Sent: Thursday, September 04, 2003 12:13 AM >> To: Jonathan Rosenberg >> Cc: midcom@ietf.org >> Subject: Re: [midcom] STUN - NAT Discovery gap in logic? >> >> >> Comments/queries inlined (previous inserts kept for context): >> >>>> * - The first time Test 1 is executed (request sent to a1:p1) a >>>> valid response is returned, but the IP address is not the same. >>>> >>>> * - Test 2 (request sent to a1:p1) no response is obtained >>>> >>>> * - Here's the issue I feel. Test 1 is executed again >> (request sent >>>> to a2:p2) but does not get a response. The diagram and text that >>>> precedes it does not explain what should happen if no response is >>>> obtained. >>> >>> Normally one would be received. >> >> I would have thought this would have been the case too, >> however while testing against some well known publically >> available STUN servers connections were refused to the >> CHANGED-ADDRESS details. >> >> >>>> No response from the execution of Test 1 a second time to >> a2:p2 may >>>> fail for a number of reasons (misconfiguration of the server, >>>> firewall open for outbound STUN requests but no other >> ports, etc.), >>>> and I don't think it's a safe assumption that a response will be >>>> receieved. >>> >>> As you say, its hard to deduce a specific problem from a lack of a >>> response. I will say that STUN is not meant to deduce firewall >>> policies, but rather nat policies. If you have a firewall >> that blocks >>> all ports but stun, this will not be detected, as it was >> not designed >>> for that. I don't know why you would have such a >> configuration though, >>> as it would defeat the purpose of anything stun would be used for. >> >> This isn't a far fetched scenario, it could be quite >> conceivable that an enterprise could well leave the well >> known port for STUN (3478) open to traffic for the purpose of >> figuring out the NAT'd IP address from a bind response in >> test 1, but because the CHANGED-ADDRESS port number is >> arbitrary it effectively requires all outbound UDP traffic to >> not be restricted. Some paranoid network admins don't allow >> such configurations. >> >> >>>> Given this situation what should be deduced from the NAT discovery >>>> process? I've noticed that some existing clients ignore the >>>> execution of Test 1 a second time and moves right through to Test >>>> 3. Should another NAT status or error be returned instead? >>> >>> The execution of test 1 a second time is needed to differentiate >>> between symmetric and port restricted, so I dont know why >> it would be >>> skipped. >> >> It's not that it's skipped as such, it's just that if the >> logic is followed through to the letter and no response is >> obtained from the 2nd Test 1, to make a decision of whether >> or not the IP address was local or not wouldn't be valid. I >> think this greyness could be interpreted different ways by >> different people and it's this kind of point that the >> specification should resolve definitively (ie. state that >> this should be an error, or that Test 3 should be executed) >> so that everyone is reading off of the same song sheet. Not >> doing so could lead to different vendors of STUN clients >> interpreting results differently and this would be >> detrimental to the purpose of STUN in the first place. Clear >> resolution as to what happens should be catered in the RFC to >> cover a likelyhood like this, belief that things "should" >> work isn't in experience good enough in real life situations. >> >> Thanks for your response Jonathan, it was much appreciated. >> >> Les >> >> > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Sep 11 02:47:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13561 for ; Thu, 11 Sep 2003 02:47:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xLEP-0001Z4-SD for midcom-archive@odin.ietf.org; Thu, 11 Sep 2003 02:47:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8B6l5U1006008 for midcom-archive@odin.ietf.org; Thu, 11 Sep 2003 02:47:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xLEL-0001YR-EH; Thu, 11 Sep 2003 02:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xLDf-0001Xs-Nn for midcom@optimus.ietf.org; Thu, 11 Sep 2003 02:46:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13556 for ; Thu, 11 Sep 2003 02:46:13 -0400 (EDT) From: les.carter@newkinetics.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xLDb-0006Jl-00 for midcom@ietf.org; Thu, 11 Sep 2003 02:46:15 -0400 Received: from sentinel.newkinetics.com ([66.92.184.212] helo=workhorse.newkinetics.com) by ietf-mx with esmtp (Exim 4.12) id 19xLDa-0006Jd-00 for midcom@ietf.org; Thu, 11 Sep 2003 02:46:15 -0400 Received: from workhorse.newkinetics.com (localhost [127.0.0.1]) by workhorse.newkinetics.com (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id h8B6vUs4025078; Wed, 10 Sep 2003 23:57:30 -0700 Received: (from carterl@localhost) by workhorse.newkinetics.com (8.12.2/8.12.2/Submit) id h8B6vUjW025077; Wed, 10 Sep 2003 23:57:30 -0700 Date: Wed, 10 Sep 2003 23:57:30 -0700 Message-Id: <200309110657.h8B6vUjW025077@workhorse.newkinetics.com> X-Authentication-Warning: workhorse.newkinetics.com: carterl set sender to les.carter@newkinetics.com using -f Subject: Re: [midcom] STUN - NAT Discovery gap in logic? To: Cullen Jennings Cc: Yutaka Takeda , Midcom , Jonathan Rosenberg X-Originating-IP: 10.1.1.118 X-Mailer: Usermin 1.000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bound1063263450" X-Virus-Scanned: by amavis-milter (http://amavis.org/) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --bound1063263450 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit The RFC does actually state that requests should be spaced out starting from 100ms doubling every request until 1.6s spacing is found and ultimately 9 requests have been sent. This however is not the cause of the problem originally stated, just one of the many symptoms that can occur and leave the client in a state of unknown going by the original logic. See a post I made, listed in the archive (http://www.ietf.org/mail-archive/working-groups/midcom/current/maillist.html) under September 9th, with a proposal for alteration to the logic to ensure that there's no room for different intepretation of the vague state that can occur. L Cullen Jennings wrote .. > > You might want to put a little bit of time (like 10 ms) between sending > each > of your packets. This tends to prevent the problem of the NAT thinking > it is > under a DOS attack. > > On 9/8/03 19:28, "Yutaka Takeda" wrote: > > > > > I have experienced the same situation with a router, not receiving a > > response in the second Test 1. I treated it as "UDP BLOCKED", > > however, the situation is a little worse than that. > > > > The router we have tested with STUN has a firewall integrated. The > > router does not forward responses at the second Test 1 from a STUN > > server to a STUN client though the client has sent to a packet to a > > transport address from which the responses are sent. > > > > The reason I found later on was that in Test 2 before the second Test > 1 > > the firewall that received multiple packets from unknown address > > treated the packets as an attack and dropped all the subsequent > > packets from the same address. This is why the response in the > > second Test1 did not arrive. To make matters worse, any packets > > from the address are ignored, and in order to reset this blockage > > with the router, I had to ask a network admin to do so... (manual > > reset) > > > > I would like to come up with a solution to this, however, so far I have > > nothing but just treating this case as being resulted in > > "UDP BLOCKED". > > > > Any opinions or suggestions to this will be appreciated. > > Yutaka > > > > > >> -----Original Message----- > >> From: les.carter@newkinetics.com [mailto:les.carter@newkinetics.com] > >> Sent: Thursday, September 04, 2003 12:13 AM > >> To: Jonathan Rosenberg > >> Cc: midcom@ietf.org > >> Subject: Re: [midcom] STUN - NAT Discovery gap in logic? > >> > >> > >> Comments/queries inlined (previous inserts kept for context): > >> > >>>> * - The first time Test 1 is executed (request sent to a1:p1) a > >>>> valid response is returned, but the IP address is not the same. > >>>> > >>>> * - Test 2 (request sent to a1:p1) no response is obtained > >>>> > >>>> * - Here's the issue I feel. Test 1 is executed again > >> (request sent > >>>> to a2:p2) but does not get a response. The diagram and text that > >>>> precedes it does not explain what should happen if no response is > >>>> obtained. > >>> > >>> Normally one would be received. > >> > >> I would have thought this would have been the case too, > >> however while testing against some well known publically > >> available STUN servers connections were refused to the > >> CHANGED-ADDRESS details. > >> > >> > >>>> No response from the execution of Test 1 a second time to > >> a2:p2 may > >>>> fail for a number of reasons (misconfiguration of the server, > >>>> firewall open for outbound STUN requests but no other > >> ports, etc.), > >>>> and I don't think it's a safe assumption that a response will be > >>>> receieved. > >>> > >>> As you say, its hard to deduce a specific problem from a lack of a > >>> response. I will say that STUN is not meant to deduce firewall > >>> policies, but rather nat policies. If you have a firewall > >> that blocks > >>> all ports but stun, this will not be detected, as it was > >> not designed > >>> for that. I don't know why you would have such a > >> configuration though, > >>> as it would defeat the purpose of anything stun would be used for. > >> > >> This isn't a far fetched scenario, it could be quite > >> conceivable that an enterprise could well leave the well > >> known port for STUN (3478) open to traffic for the purpose of > >> figuring out the NAT'd IP address from a bind response in > >> test 1, but because the CHANGED-ADDRESS port number is > >> arbitrary it effectively requires all outbound UDP traffic to > >> not be restricted. Some paranoid network admins don't allow > >> such configurations. > >> > >> > >>>> Given this situation what should be deduced from the NAT discovery > >>>> process? I've noticed that some existing clients ignore the > >>>> execution of Test 1 a second time and moves right through to Test > >>>> 3. Should another NAT status or error be returned instead? > >>> > >>> The execution of test 1 a second time is needed to differentiate > >>> between symmetric and port restricted, so I dont know why > >> it would be > >>> skipped. > >> > >> It's not that it's skipped as such, it's just that if the > >> logic is followed through to the letter and no response is > >> obtained from the 2nd Test 1, to make a decision of whether > >> or not the IP address was local or not wouldn't be valid. I > >> think this greyness could be interpreted different ways by > >> different people and it's this kind of point that the > >> specification should resolve definitively (ie. state that > >> this should be an error, or that Test 3 should be executed) > >> so that everyone is reading off of the same song sheet. Not > >> doing so could lead to different vendors of STUN clients > >> interpreting results differently and this would be > >> detrimental to the purpose of STUN in the first place. Clear > >> resolution as to what happens should be catered in the RFC to > >> cover a likelyhood like this, belief that things "should" > >> work isn't in experience good enough in real life situations. > >> > >> Thanks for your response Jonathan, it was much appreciated. > >> > >> Les > >> > >> > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > --bound1063263450-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Sep 11 07:46:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19017 for ; Thu, 11 Sep 2003 07:46:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xPtu-00033D-0L for midcom-archive@odin.ietf.org; Thu, 11 Sep 2003 07:46:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BBkDUv011723 for midcom-archive@odin.ietf.org; Thu, 11 Sep 2003 07:46:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xPth-00032Y-T2; Thu, 11 Sep 2003 07:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xPtX-00032D-Ae for midcom@optimus.ietf.org; Thu, 11 Sep 2003 07:45:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19010 for ; Thu, 11 Sep 2003 07:45:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xPtW-0000Rx-00 for midcom@ietf.org; Thu, 11 Sep 2003 07:45:50 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19xPtV-0000Rn-00 for midcom@ietf.org; Thu, 11 Sep 2003 07:45:50 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.9) with ESMTP id h8BBj5gu054013; Thu, 11 Sep 2003 13:45:06 +0200 (CEST) Received: from [10.1.1.171] (m-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 0D318C75DA; Thu, 11 Sep 2003 13:17:11 +0200 (CEST) Date: Thu, 11 Sep 2003 13:45:50 +0200 From: =?ISO-8859-1?Q?J=FCrgen_Quittek?= To: j.schoenwaelder@iu-bremen.de, Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] Reminder: wg last call Message-ID: <2147483647.1063287950@[10.1.1.171]> In-Reply-To: <20030904075616.GA695@iu-bremen.de> References: <82278E42-DE42-11D7-BF27-000A95E35274@cisco.com> <20030904075616.GA695@iu-bremen.de> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Juergen, I understand your concerns. They can be addressed by moving transactions Policy Rule List (PRL) and Policy Rule Status (PRS) from optional to mandatory. Still I do not have a strong feeling about whether or not applying this change. But if not one objects on the list, I'm fine with applying it to the next version. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 04.09.2003 9:56 Uhr +0200 Juergen Schoenwaelder wrote: > On Wed, Sep 03, 2003 at 03:12:06PM -0400, Melinda Shore wrote: > >> This is a reminder that we're in WG last call on the semantics >> document. Last call closes on Tuesday, 9 September. The URL >> for the document is: >> >> http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-04.txt > > I will once more bring up a comment which I did already made when I > reviewed the previous revision of the document and where I did not > see much of a discussion. > > I am still concerned about making all transactions that allow to > retrieve what is actually installed on a device optional. For > debugging and development purposes, I believe it is essential > to be able to retrieve the installed policies and groups. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Sep 11 08:01:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19272 for ; Thu, 11 Sep 2003 08:01:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xQ8E-0003Ho-J1 for midcom-archive@odin.ietf.org; Thu, 11 Sep 2003 08:01:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BC12sr012607 for midcom-archive@odin.ietf.org; Thu, 11 Sep 2003 08:01:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xQ8D-0003H2-LY; Thu, 11 Sep 2003 08:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xQ7w-0003Gb-0X for midcom@optimus.ietf.org; Thu, 11 Sep 2003 08:00:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19259 for ; Thu, 11 Sep 2003 08:00:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xQ7v-0000Wj-00 for midcom@ietf.org; Thu, 11 Sep 2003 08:00:43 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19xQ7u-0000Wc-00 for midcom@ietf.org; Thu, 11 Sep 2003 08:00:42 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.9) with ESMTP id h8BC09gu055003; Thu, 11 Sep 2003 14:00:10 +0200 (CEST) Received: from [10.1.1.171] (m-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 22501C75F7; Thu, 11 Sep 2003 13:32:14 +0200 (CEST) Date: Thu, 11 Sep 2003 14:00:53 +0200 From: =?ISO-8859-1?Q?J=FCrgen_Quittek?= To: Pyda Srisuresh , midcom@ietf.org Cc: stiemerling@ccrle.nec.de, taylor@nortelnetworks.com Subject: Re: [midcom] Reminder: wg last call Message-ID: <2147483647.1063288853@[10.1.1.171]> In-Reply-To: <20030906211547.79199.qmail@web40401.mail.yahoo.com> References: <20030906211547.79199.qmail@web40401.mail.yahoo.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pyda, Thanks for your comments. Please see replies to some of them inline. --On 06.09.2003 14:15 Uhr -0700 Pyda Srisuresh wrote: > Below is text of the e-mail (a little revised) I sent to the authors earlier. I > am including the text for wider audience. Below are my outstanding comments on > the draft. > > 1. For a NAT middlebox, I believe, the semantics ought to cover the following > transactions. My comments assume the following. > > A. NAT is configured on a per-interface basis. As such, the > Midcom/NAT transactions would be specified on a per-interface basis. I do not share this view. A midcom agent has the intention and capability to specify endpoints of communication across the middlebox. Which interfaces of the middlebox are affected is not subject of midcom transactions. The MIDCOM information model simplifies the network view by just separating an internal network and an external network. Whether or not the middlebox has one or more interfaces connected to any of them is considered an internal matter of the middlebox. There is no statement in framework or requirements that oblige an agent to find out which interfaces a middlebox is using. > B. End-point below is to be refered as > for a PortBind. End-point for an address Bind will be > . The IP address can be V4 or V6. > C. The transactions specified below can be applicable to one or more > end-points. This will include address ranges, address > wild-carding, port ranges, and port wild-carding. > > > SetMapOwner [Full | Partial] [] > - SetMapowner may be used by an agent to claim > ownership on a complete NAT map entry or a > portion of the entry. AgentId will be set as the > owner of the entire map entry or portion thereof. > > (CreateBind | CreatePortBind) > > - Agent specifies all the requisite Parameters for > Bind(s) or PortBind(s). Agent requests middlebox > to create a BIND and respond back with an assigned > BindId. Middlebox to validate the authorization > prior to responding. > > (RequestCreateBind | RequestPortCreateBind) > [Oddity option] > - Agent requests the Middlebox to create BIND(s) for > the given End-point, optionally with an Oddity > requirement. Middlebox to validate the > authorization, prior to assgining a BIND and > a BindId and returning the response. > > CreateOutboundSession > | > | > > > - Agent specifies all the requisite Parameters for > an outbound session. Agent requests middlebox > to create a session as specified and respond back > with an assigned BindId. > The session may have one or two end-point > translations. The session may be derived directly > from the address map (or) from associated Bind-IDs. > Middlebox to validate the authorization prior to > responding. Note, the session tuple may have > wild-card elements. > > RequestCreateOutboundSession > | > | > > - Agent requests the Middlebox to create an outbound > session for the given session tuple, using one or > more map entries and/or end-point BINDs. Agent > to validate he authorization prior to responding > back with a new session and session-id. As before, > the session tuple may have wild-card elements. > > CreateInboundSession, > RequestCreateInboundSession > - Similar to the outbound counterparts. > > ModifyBindParameters > [] [MaximumIdletime>] [] > - These parameters may be specified either at Bind > creation time or later. > > ModifySessionParameters > [] [MaximumIdletime>] [] > - These parameters may be specified either at session > creation time or later. Note, session here refers > to the NAT data sessions, not the Midcom agent > session. > > In particular, I would like to mention the notion of three resources > a NAT middlebox and midcom agent need to be cognizant of - > Address map entries, Binds and sessions. These resources may be a) created by > the agent, b) created by the NAT middlebox, or c) paramaters modified by the > agent. The way I see it, MIDCOM does not distinguish binding and session (as the NAT MIB does). The point is that the MIDCOM protocol is not a middlebox management protocol, but a protocol that allows applications to express requests for enabling communication across a middlebox. > 2. The notion of PRR is incomplete without the context of the entire address > map entry. The reservation may not be specific to address/address-port alone. > My view of this is simply that PRR is just another notion of ownership claim. > it just happens to be in relation to an address map entry. The intention behind PRR is just to reserve addresses at the middlebox. This can be doen without mapping them already. > 3. When you combine the notion of PRR wth PER, the state transition diagram in > section 2.3.13 woudl be simplified, with the proviso that there would be three > types of policy rules (address map entries, binds and sessions). Again, binds and sessions cannot be distinguished in the midcom world. > 4. I agree with your notion of Session establishment and session termination > transactions. > > 5. I believe, the group Ids an agent would use during the lifetime of a Midcom > session should be specified by the agent - either at the midcom session > establishment time or afterwards whild the midcom session is alive. Given that > group-Ids are specific to an agent, it shoudl be agent's responsibility to > assign group IDs, not that of the middlebox's. Further, given that there are 3 Group IDs need to be unique per middlebox. This is hard to achieve if the agent assigns them. > different types of resources (map entries, Binds and sessions), there shoudl be > three different sets of group-Ids, one set for each resource type. > Middlebox will assign a default groupId of 0 to all entities that are not > assigned a groupId by the agent. I prefer to have reservation rules and enable rules (bindings) to be able to share a group. because then the agent can extend or delete sets of them belonging together by just accessing a single group. Cheers, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de > regards, > suresh > > > --- Melinda Shore wrote: >> This is a reminder that we're in WG last call on the semantics >> document. Last call closes on Tuesday, 9 September. The URL >> for the document is: >> >> http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-04.txt >> >> Melinda >> >> >> _______________________________________________ >> midcom mailing list >> midcom@ietf.org >> https://www1.ietf.org/mailman/listinfo/midcom > > > ===== > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Sep 11 08:39:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20210 for ; Thu, 11 Sep 2003 08:39:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xQj1-0004h3-9F for midcom-archive@odin.ietf.org; Thu, 11 Sep 2003 08:39:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BCd3DG018032 for midcom-archive@odin.ietf.org; Thu, 11 Sep 2003 08:39:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xQiz-0004gM-W4; Thu, 11 Sep 2003 08:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xQiP-0004fq-Tk for midcom@optimus.ietf.org; Thu, 11 Sep 2003 08:38:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20187 for ; Thu, 11 Sep 2003 08:38:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xQiO-0000pM-00 for midcom@ietf.org; Thu, 11 Sep 2003 08:38:24 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19xQiN-0000p6-00 for midcom@ietf.org; Thu, 11 Sep 2003 08:38:24 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.9) with ESMTP id h8BCbqgu060220; Thu, 11 Sep 2003 14:37:52 +0200 (CEST) Received: from [10.1.1.171] (m-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 3E18AC765C; Thu, 11 Sep 2003 14:09:57 +0200 (CEST) Date: Thu, 11 Sep 2003 14:38:37 +0200 From: =?ISO-8859-1?Q?J=FCrgen_Quittek?= To: Daniel Fonseca , midcom@ietf.org Subject: Re: [midcom] Reminder: wg last call Message-ID: <2147483647.1063291117@[10.1.1.171]> In-Reply-To: <20030909145002.32784.qmail@web13104.mail.yahoo.com> References: <20030909145002.32784.qmail@web13104.mail.yahoo.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Daniel, Thank you very much for all your comments. Most of them are very helpful and we will apply them. Please see detailed replies inline. --On 09.09.2003 7:50 -0700 Daniel Fonseca wrote: > Dear WG members, > > I am in the final semester of Computer Science, and > the subject of my undergraduate qualifying project > will be the kind of service this WG is attempting to > offer, with more focus on midcom itself. > I have read the midcom RFCs and drafts written so > far, the mailing list messages, and part of the UPnP > documentation, but I have found very little more about > that kind of firewall/NAT/"middlebox" configuration on > the internet. There are a few presentations and > proprietary solutions, yet none of them discuss the > subject nearly as deep, or suggest a solution with the > required robustness and/or flexibility. > If you know any other source of information regarding > this subject, either papers, web sites, presentations > or documentation of any sort, I would appreciate it if > you would send it to me. > I have prepared my own set of comments on the latest > revision of the semantics, they are copied below. > Although most are type/grammar misspellings, maybe it > can be of some use to you. > > Thanks in advance, > > Daniel Fonseca > dfonseca@ufrj.br > > ------------------------- > ------------------------- > > Page 3, "... and the (4) reply and notification > messages send from the middlebox to the agent ...". > Should be "messages sent from the middlebox", right? Right. Fixed. > Page 7, "Convenience transaction simplify MIDCOM > sessions ...". > Should be "transactions". Fixed. > Page 10, "... configuration of authorization at the > middelbox is ...". > Should be "middlebox". Fixed. > Page 10, "- internal IP address wildcard support > - external IP address wildcard support" > (I believe this has been mentioned recently in the > list) > It is very common for middlebox-ish devices to have > more than two interfaces. How is midcom going to > handle that? Shouldn't there be an interface-id? This > involves many other sections in the text. In the MIDCOM information model there is just an internal (protected, private, ...) network and and external (public?) network. How many interfaces of a middlebox are connected to which of these two networks is not of interest to applications requesting the box to just ENABLE communication between two specified end points. Which interfaces are involved in serving such a request needs to be identified by the middlebox internally. > Page 11, section 2.1.8: "A mandatory request > transaction must be offered to each of the > authenticated agents." > I think this paragraph gets confusing when it > approaches the difference between mandatory-optional > and (un)authorized transactions. Maybe not all > mandatory transactions should be offered to all > agents, and each agent could be offered only the > transactions it is authorized to perform. Is that off > scope? You are right. This is confusing. We will re-phrase this paragraph in a - hopefully- much clearer way when editing the next version. > Page 12, "All transaction are transmitted within this > MIDCOM session." > Should be "All transactions are ...", or even "Every > transaction must be ...". Fixed. > Page 16, Figure 2. > Forgive me if I have skipped or forgotten something, > but with the info up to this point in the text, I had > no clue how "mc=0" relates to a successful middlebox > challenge. The idea is understood, but why is mc > supposed to be 0, not "OK" or "success"? Well, the intention was to say "mc=empty". Another point where re-phrasing is required for the next version. > Page 18, "Each policy rule is member of exactly one > policy rule group." > Although this seems to be a deliberate decision, but I > would like to know why a rule can't be on more than > one group, for it could be helpful. Ease of > implementation? Not just of the implementation. Also of the specification. If you want to have multiple membership, you need additional transactions or extended existing transactions configuring this and probably also changing a policy rule's membership. Is there a trong requirement that justifies such an increase in complexity? > Page 20, "... address tuple A0 specifies a > communication endpoint of a devices within ..." > Should be either "of all devices", "of a device", or > even "of devices". "a device" is correct. Fixed. > Page 21, "For the transport protcols TCP and UDP ..." > Should be "protocols". Fixed. > Page 21, "The MIDCOM semantics defined in this > document define the handling of IPv4 and IPv6 as We should replace "define" by "specifies". > network protocols. For the transport protcols TCP and > UDP over either IPv4 or IPv6 are supported." > I believe readability would improve if it were > rephrased as "The MIDCOM semantics defined in this > document define the handling of IPv4 and IPv6 as > network protocols, and of TCP and UDP (over IPv4 or > IPv6) as transport protocols." Yes, thank you. > Page 21, "The value of the transport protocol > parameter can have one of the following values: 'TCP', > 'UDP', 'ANY'." > The value can have a value? Just for clarification, > this could be rephrased as "The value of the transport > protocol parameter can be either 'TCP', 'UDP' or > 'ANY'." Fixed. > Page 22, the last paragraph of section 2.3.6. > That's a verbose description of what a port range > means. Assuming the reader is familiar with the > normative reference documents, I think that entire > paragraph is unnecessary. Can you give a good normative reference defining "port range"? > Page 23, "- mode: the requested NAT mode of the > middlebox. Allowed values are 'traditional' or > 'twice'." > How about changing the name of this paramenter to > "service", or something more flexible than "mode". I > think that would maintain current meaning, and allow > other types of services (maybe firewall could have its > own service). Agreed. > Page 25, "The middelbox always reserves ..." > Should be "middlebox". Fixed. > Page 28, "This transactions can be used ..." > Should be "This transaction". Fixed. > Page 32, "A failure reply implies that the lifetime of > the policy rule remains unchanged. A success reply is > generated by the middlebox, if the lifetime of the > policy rule was changed in any way." > I know this should hardly ever happen, but the case of > a RLC attempting to set the new lifetime to the exact > current lifetime value was not covered. That should be > a success, right? How about rephrasing the first > sentence above to "A failure reply implies that the > new lifetime was not accepted, and the policy rule > remains unchanged." ? Good catch! Fixed. > Page 34, "- port range: the number of consecutive > ports numbers, see Section 2.3.5." > Should be "consecutive port numbers". Fixed. > Page 43, "This multiple fine-grained transactions must > further met the atomicity requirement stated in > section 2.1.3." > Should be "These multiple fine-grained transactions > must further meet the atomicity ..." Fixed. > __________________________________ > Do you Yahoo!? No, I don't. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Sep 11 12:06:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28930 for ; Thu, 11 Sep 2003 12:06:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xTxS-00050g-LP for midcom-archive@odin.ietf.org; Thu, 11 Sep 2003 12:06:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BG6AXd019258 for midcom-archive@odin.ietf.org; Thu, 11 Sep 2003 12:06:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xTxK-000508-HG; Thu, 11 Sep 2003 12:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xTxB-0004zo-MW for midcom@optimus.ietf.org; Thu, 11 Sep 2003 12:05:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28901 for ; Thu, 11 Sep 2003 12:05:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xTxA-0002m9-00 for midcom@ietf.org; Thu, 11 Sep 2003 12:05:52 -0400 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 19xTx9-0002lp-00 for midcom@ietf.org; Thu, 11 Sep 2003 12:05:51 -0400 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id AB4F655ACE; Thu, 11 Sep 2003 18:05:19 +0200 (CEST) Received: from james (unknown [212.201.47.15]) by merkur.iu-bremen.de (Postfix) with ESMTP id 8B0A755A66; Thu, 11 Sep 2003 18:05:15 +0200 (CEST) Received: by james (Postfix, from userid 1000) id D067B8516; Thu, 11 Sep 2003 18:05:10 +0200 (CEST) Date: Thu, 11 Sep 2003 18:05:10 +0200 From: Juergen Schoenwaelder To: rrohit74@hotmail.com, npai@cisco.com, raraghun@cisco.com, cliffwang2000@yahoo.com, srisuresh@yahoo.com Cc: bwijnen@lucent.com, midcom@ietf.org Message-ID: <20030911160510.GA3758@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: rrohit74@hotmail.com, npai@cisco.com, raraghun@cisco.com, cliffwang2000@yahoo.com, srisuresh@yahoo.com, bwijnen@lucent.com, midcom@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 Subject: [midcom] NAT-MIB review Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Bert asked me to play the MIB doctor for the NAT-MIB and so I have reviewed . The document needs further editorial work in order to comply with the MIB guidelines as documented in and there are several technical questions that need to be discussed and resolved before the document is ready to go. 1) The abstract should not contain references, see also the guidelines document. 2) I suggest to add definitions of key terms into section 3. In particular, I would like to see a definition for concepts such as sessions, groups and probably owners. Also the relationship to other MIDCOM work needs to be explained since the MIB module talks about "MIDCOM compliance" and I have no clue what that means (see also below). 3) In the overview section, you should say that this MIB module depends in some parts on the IF-MIB. 4) In the overview section, please introduce the names of the tables and use these names where appropriate to reduce any risk for confusion. Some phrases I think are a bit confusing, e.g. o two scalars used to monitor address thresholds and generate notifications when the thresholds are crossed. I do not think you monitor thresholds. In fact, these thresholds define when notifications are generated. (And my later reading of the MIB makes me wonder whether the second one is ever used.) 5) typo "... the currently exist ..." -> "... that currently exist ..." 6) Section 4.1 says: The association between the various configuration tables can be represented as follows: per interface config (global config parameters) | | | | | | |----------------------------| | | address map My understanding is that the global config parameters are just a few scalars and not a table. 7) Section 4.3 says that binds which point to non-existing address maps are not allowed. In the MIB definitions, it would be very useful to say precisely what happens if one tries to violate the rule (that is, which error code is actually generated when I try to delete an address map with pending binds or try to create a bind which points to a non-existing address map). 8) You seem to use the RowStatus for two purposes - creating/destroying rows as well as enabling/disabling them. The compliance allows implementations that do only one-shot row creation and deletion, which means that those implementations do not have the capability to disable a row. Also note that a row in the notInService state has a timer attached so the row cannot be in that state for longer periods of time. Perhaps you want to introduce explicit enabled/disabled states for the rows in question in case it makes sense. 9) The start of the module needs editorial work so that it conforms to section 4.5 in the MIB review guidelines document. 10) I suggest to also make the bit set representation of the protocol types an explicit TC so that both TCs are close together which reduces any maintenance issues. 11) What does an idle timeout of 0 seconds actually mean? (This question affects natConfUdpDefIdleTimeout, natConfIcmpDefIdleTimeout, natConfOtherDefIdleTimeout, natConfTcpDefIdleTimeout and natConfTcpDefNegTimeout. 12) I suggest to reword the description of the TCP idle timeout objects: natConfTcpDefIdleTimeout: The default time interval a NAT session (or is it a binding or both?) for an established TCP connection is allowed to remain valid without any activity on the TCP connection. natConfTcpDefNegTimeout: The default time interval a NAT session (or is it a binding or both?) for a TCP connection which is not in the established state is allowed to remain valid without any activity on the TCP connection. The point here is that the phrase "TCP protocol session" confuses me - do you refer to a NAT session for a TCP connection or something else? 13) I fail to see how the notification thresholds actually work. It seems to me that actually only the natConfAddrRiseThreshold is used. If my reading is wrong, the text probably has to be improved. 14) typo "... Groupn" -> "... Group" 15) The description of the natConfInterfaceTable should probably say that this is per interface configuration (and then you can remove the comment above ;-). 16) Why do you introduce natConfInterfaceIndex and not just import and use ifIndex? 17) What are the semantics of zero-length natConfAddrMapConfigName values? Can I actually have multiple natConfAddrMapConfigName objects with the same value? If not, what happens if I try to create them? And why do you identify address maps by name when all the other entities are identified by numbers? Also, I find the description confusing since this does not according to my understanding select a set of address maps but rather a single address map. 18) The StorageType TC requires you to specify which objects are writable if the storage type is permanent - see also section 4.6.4 in the MIB review guidelines document. This is missing in all places where StorageType is being used. 19) I fail to understand the concept of the OwnerId and GoupId. What does the value 42 tell a management station? I think this concept is important to introduce in the beginning of the document. 20) What precisely happens if I write a value != 0 to natConfLocalPortFrom, natConfLocalPortTo, natConfGlobalPortFrom, natConfGlobalPortTo on a basic NAT? 21) I think the number space for address binds (e.g. natAddrBindId, natAddrPortBindId) should exclude the value 0. Perhaps it actually makes sense to introduce TCs doe NatAddrBindId and NatAddrBindIdOrZero so things will be consistent. 22) The description of natAddrBindDirection says: "This object represents the direction of the BIND. A BIND may be either uni-directional or bi-directional, same as the orientation of the address map, based on which this bind is formed." Where in the address map is the direction specified? 23) Please say precisely which error is to be generated if you set natAddrBindAddrMapName or natAddrPortBindAddrMapName to a non existent addrMapName. 24) Should natAddrBindMaxIdleTime natAddrPortBindMaxIdleTime and natSessionMaxIdleTime not use syntax TimeInterval instead of TimeTicks? 25) You may want to rename all counters ending in *Translate to *Translates to follow the old rules that counters are in plural. 26) The natAddrBindTable, natAddrPortBindTable and natSessionTable have no StorageType, see the MIB review guidelines document. (In general, one can also ask why these tables are not part of the configuration branch since I can do row creation here. Also there are counters in the translation tables which are actually statistics. Personally, I would just drop the branches since they serve no real value and only increase the length of the OIDs.) 27) What is the "query id" you refer to in the description of natAddrPortBindLocalPort and natAddrPortBindGlobalPort? If you mean the ICMP type code, then please say ICMP type code. 28) In the number space for session, you really want to exclude the value 0. Again, it might help to introduce specific TC(s). 29) What is the relationship between binds and sessions? Your MIB is modelled as if it is 1:n, that is you can have n sessions for one bind. Is that the case? 30) Is there redundant information? Can a session have a different protocol type than the associated binds? Or why are natSessionProtocolType and friends needed? 31) Looking at this description: natStatsAddrMapAddrUsed OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of addresses, pertaining to this address map, that are currently being used from the nat pool. The value of this object is irrelevant if the address map in question is a static address map." ::= { natStatsAddrMapEntry 6 } What does it mean that the object is irrelevant? Should it still be implemented (if not clarify in the compliance definition). If implemented, should it still report the correct value or can it contain arbitrary garbage? 32) I propose to rename the following objects for consistency: natStatsInterfacePktsIn -> natStatsInterfaceInTranslates natStatsInterfacePktsOut -> natStatsInterfaceOutTranslates 33) I suggest to change the notification registration as follows: natMIBNotifications OBJECT IDENTIFIER ::= { natMIB 0 } natAddressUseRising NOTIFICATION-TYPE -- yada yada ::= { natMIBNotifications 1 } natPacketDiscard NOTIFICATION-TYPE -- yada yada ::= { natMIBNotifications 2 } This again saves a sub-identifier and makes things more compact. 34) The description of natAddressUseRising makes me beliefe that the falling threshold is actually never being used. 35) Why can you not use natConfAddrMapName instead of natAddrMapName in the natPacketDiscard notification? And since you only distinguish two discard reasons, why do you not simply use two different notifications? This would avoid the introduction of natPktDiscardReason. (In general, accessible-for-notify is kind of a strange construction and this is why I wonder about these objects.) 36) In the compliance section, you always talk about "MIDCOM compliance" and I have no clue what that means. 37) I think there are dependencies between the natMIBNotif*Groups and you probably want to spell them out since it does not make sense to implement the natMIBNotificationGroup without the other natMIBNotif*Groups. 38) I think section 9 is not really needed since this OID assignment will happen automatically when this document is being processed. 39) In the security considerations, you simply state that "some of these objects could contain sensitive information, e.g. bind information". For someone deploying this, it might be useful to have a more explicit discussion of the security implications. 40) Remove the leading quote character in teh Full Copyright Statement section. That's it. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Sep 11 15:02:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06015 for ; Thu, 11 Sep 2003 15:02:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWhh-0003Fu-Vk for midcom-archive@odin.ietf.org; Thu, 11 Sep 2003 15:02:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BJ25aq012513 for midcom-archive@odin.ietf.org; Thu, 11 Sep 2003 15:02:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWhd-0003FQ-JK; Thu, 11 Sep 2003 15:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWhX-0003Ex-8R for midcom@optimus.ietf.org; Thu, 11 Sep 2003 15:01:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06004 for ; Thu, 11 Sep 2003 15:01:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xWhU-0004SJ-00 for midcom@ietf.org; Thu, 11 Sep 2003 15:01:52 -0400 Received: from 67.105.118.114.ptr.us.xo.net ([67.105.118.114] helo=mail.kmerl.com) by ietf-mx with esmtp (Exim 4.12) id 19xWhT-0004S8-00 for midcom@ietf.org; Thu, 11 Sep 2003 15:01:51 -0400 content-class: urn:content-classes:message Subject: RE: [midcom] STUN - NAT Discovery gap in logic? Date: Thu, 11 Sep 2003 12:01:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [midcom] STUN - NAT Discovery gap in logic? Thread-Index: AcN4LA14VK/dsheiRMi1dGt6HC80cgAZBveA From: "Yutaka Takeda" To: "Cullen Jennings" , Cc: "Midcom" , "Jonathan Rosenberg" Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I wonder how much it is worth discussing one particular router's behavior, however, the router I mentioned reacted to the=20 re-transmission defined in RFC 3489 as Les mentioned. Is the 10 ms interval time a general practice to prevent it? Is=20 there a public reference for the interval time between packets=20 from an unknown source that will be considered as DOS attack? This might encourage a use of ICE, checking connectivity before=20 sending media packets in order to avoid unnecessary firewall=20 blockage, or might not because the connectivity check with STUN itself might be treated as a DoS attack or a port scanning=20 depending on configuration of a firewall. Yutaka > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Wednesday, September 10, 2003 11:15 PM > To: Yutaka Takeda; les.carter@newkinetics.com > Cc: Midcom; Jonathan Rosenberg > Subject: Re: [midcom] STUN - NAT Discovery gap in logic? >=20 >=20 >=20 > You might want to put a little bit of time (like 10 ms)=20 > between sending each > of your packets. This tends to prevent the problem of the NAT=20 > thinking it is > under a DOS attack. >=20 > On 9/8/03 19:28, "Yutaka Takeda" wrote: >=20 > >=20 > > I have experienced the same situation with a router, not receiving a > > response in the second Test 1. I treated it as "UDP BLOCKED", > > however, the situation is a little worse than that. > >=20 > > The router we have tested with STUN has a firewall integrated. The > > router does not forward responses at the second Test 1 from a STUN > > server to a STUN client though the client has sent to a packet to a > > transport address from which the responses are sent. > >=20 > > The reason I found later on was that in Test 2 before the=20 > second Test 1 > > the firewall that received multiple packets from unknown address > > treated the packets as an attack and dropped all the subsequent > > packets from the same address. This is why the response in the > > second Test1 did not arrive. To make matters worse, any packets > > from the address are ignored, and in order to reset this blockage > > with the router, I had to ask a network admin to do so... (manual > > reset) > >=20 > > I would like to come up with a solution to this, however,=20 > so far I have > > nothing but just treating this case as being resulted in > > "UDP BLOCKED". > >=20 > > Any opinions or suggestions to this will be appreciated. > > Yutaka > >=20 > >=20 > >> -----Original Message----- > >> From: les.carter@newkinetics.com=20 > [mailto:les.carter@newkinetics.com] > >> Sent: Thursday, September 04, 2003 12:13 AM > >> To: Jonathan Rosenberg > >> Cc: midcom@ietf.org > >> Subject: Re: [midcom] STUN - NAT Discovery gap in logic? > >>=20 > >>=20 > >> Comments/queries inlined (previous inserts kept for context): > >>=20 > >>>> * - The first time Test 1 is executed (request sent to a1:p1) a > >>>> valid response is returned, but the IP address is not the same. > >>>>=20 > >>>> * - Test 2 (request sent to a1:p1) no response is obtained > >>>>=20 > >>>> * - Here's the issue I feel. Test 1 is executed again > >> (request sent > >>>> to a2:p2) but does not get a response. The diagram and text that > >>>> precedes it does not explain what should happen if no response is > >>>> obtained. > >>>=20 > >>> Normally one would be received. > >> =20 > >> I would have thought this would have been the case too, > >> however while testing against some well known publically > >> available STUN servers connections were refused to the > >> CHANGED-ADDRESS details. > >>=20 > >>=20 > >>>> No response from the execution of Test 1 a second time to > >> a2:p2 may > >>>> fail for a number of reasons (misconfiguration of the server, > >>>> firewall open for outbound STUN requests but no other > >> ports, etc.), > >>>> and I don't think it's a safe assumption that a response will be > >>>> receieved. > >>>=20 > >>> As you say, its hard to deduce a specific problem from a lack of a > >>> response. I will say that STUN is not meant to deduce firewall > >>> policies, but rather nat policies. If you have a firewall > >> that blocks=20 > >>> all ports but stun, this will not be detected, as it was > >> not designed=20 > >>> for that. I don't know why you would have such a > >> configuration though, > >>> as it would defeat the purpose of anything stun would be used for. > >>=20 > >> This isn't a far fetched scenario, it could be quite > >> conceivable that an enterprise could well leave the well > >> known port for STUN (3478) open to traffic for the purpose of > >> figuring out the NAT'd IP address from a bind response in > >> test 1, but because the CHANGED-ADDRESS port number is > >> arbitrary it effectively requires all outbound UDP traffic to > >> not be restricted. Some paranoid network admins don't allow > >> such configurations. > >>=20 > >>=20 > >>>> Given this situation what should be deduced from the NAT=20 > discovery > >>>> process? I've noticed that some existing clients ignore the > >>>> execution of Test 1 a second time and moves right through to Test > >>>> 3. Should another NAT status or error be returned instead? > >>>=20 > >>> The execution of test 1 a second time is needed to differentiate > >>> between symmetric and port restricted, so I dont know why > >> it would be=20 > >>> skipped. > >>=20 > >> It's not that it's skipped as such, it's just that if the > >> logic is followed through to the letter and no response is > >> obtained from the 2nd Test 1, to make a decision of whether > >> or not the IP address was local or not wouldn't be valid. I > >> think this greyness could be interpreted different ways by > >> different people and it's this kind of point that the > >> specification should resolve definitively (ie. state that > >> this should be an error, or that Test 3 should be executed) > >> so that everyone is reading off of the same song sheet. Not > >> doing so could lead to different vendors of STUN clients > >> interpreting results differently and this would be > >> detrimental to the purpose of STUN in the first place. Clear > >> resolution as to what happens should be catered in the RFC to > >> cover a likelyhood like this, belief that things "should" > >> work isn't in experience good enough in real life situations. > >>=20 > >> Thanks for your response Jonathan, it was much appreciated. > >>=20 > >> Les > >>=20 > >>=20 > >=20 > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > >=20 >=20 >=20 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Sep 12 09:26:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21222 for ; Fri, 12 Sep 2003 09:26:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xnw6-0004rZ-0e for midcom-archive@odin.ietf.org; Fri, 12 Sep 2003 09:26:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CDQ5ch018689 for midcom-archive@odin.ietf.org; Fri, 12 Sep 2003 09:26:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xnw1-0004qz-8z; Fri, 12 Sep 2003 09:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xnvB-0004pg-9X for midcom@optimus.ietf.org; Fri, 12 Sep 2003 09:25:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21054 for ; Fri, 12 Sep 2003 09:25:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xnv9-0006Jk-00 for midcom@ietf.org; Fri, 12 Sep 2003 09:25:07 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19xnv9-0006IW-00 for midcom@ietf.org; Fri, 12 Sep 2003 09:25:07 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h8CDOWB09737 for ; Fri, 12 Sep 2003 08:24:32 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Fri, 12 Sep 2003 15:24:31 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502331524@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'j.schoenwaelder@iu-bremen.de'" , rrohit74@hotmail.com, npai@cisco.com, raraghun@cisco.com, cliffwang2000@yahoo.com, srisuresh@yahoo.com Cc: "Wijnen, Bert (Bert)" , midcom@ietf.org Date: Fri, 12 Sep 2003 15:23:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: [midcom] RE: NAT-MIB review Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Thanks Juergen. So I expect the authors to respond/comment back, and to most probably issue another revision to address the issues. Pls copy me explicitly on any follow up communication, cause I am currently not subscribed to midcom list. Thanks, Bert > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: donderdag 11 september 2003 18:05 > To: rrohit74@hotmail.com; npai@cisco.com; raraghun@cisco.com; > cliffwang2000@yahoo.com; srisuresh@yahoo.com > Cc: bwijnen@lucent.com; midcom@ietf.org > Subject: NAT-MIB review > > > Bert asked me to play the MIB doctor for the NAT-MIB and so I have > reviewed . The document needs further > editorial work in order to comply with the MIB guidelines as > documented in and there > are several technical questions that need to be discussed and resolved > before the document is ready to go. > > 1) The abstract should not contain references, see also the > guidelines > document. > > 2) I suggest to add definitions of key terms into section 3. In > particular, I would like to see a definition for concepts such > as sessions, groups and probably owners. Also the relationship > to other MIDCOM work needs to be explained since the MIB module > talks about "MIDCOM compliance" and I have no clue what that > means (see also below). > > 3) In the overview section, you should say that this MIB module > depends in some parts on the IF-MIB. > > 4) In the overview section, please introduce the names of the tables > and use these names where appropriate to reduce any risk for > confusion. Some phrases I think are a bit confusing, e.g. > > o two scalars used to monitor address thresholds and generate > notifications when the thresholds are crossed. > > I do not think you monitor thresholds. In fact, these thresholds > define when notifications are generated. (And my later reading of > the MIB makes me wonder whether the second one is ever used.) > > 5) typo "... the currently exist ..." -> "... that currently > exist ..." > > 6) Section 4.1 says: > > The association between the various configuration tables can be > represented as follows: > > > per interface config (global config parameters) > | | > | | > | | > |----------------------------| > | > | > address map > > My understanding is that the global config parameters are just > a few scalars and not a table. > > 7) Section 4.3 says that binds which point to non-existing address > maps are not allowed. In the MIB definitions, it would be very > useful to say precisely what happens if one tries to violate the > rule (that is, which error code is actually generated when I try > to delete an address map with pending binds or try to create a > bind which points to a non-existing address map). > > 8) You seem to use the RowStatus for two purposes - > creating/destroying rows as well as enabling/disabling them. The > compliance allows implementations that do only one-shot row > creation and deletion, which means that those implementations > do not have the capability to disable a row. Also note that a > row in the notInService state has a timer attached so the row > cannot be in that state for longer periods of time. > > Perhaps you want to introduce explicit enabled/disabled states for > the rows in question in case it makes sense. > > 9) The start of the module needs editorial work so that it conforms > to section 4.5 in the MIB review guidelines document. > > 10) I suggest to also make the bit set representation of the protocol > types an explicit TC so that both TCs are close together which > reduces any maintenance issues. > > 11) What does an idle timeout of 0 seconds actually mean? (This > question affects natConfUdpDefIdleTimeout, > natConfIcmpDefIdleTimeout, natConfOtherDefIdleTimeout, > natConfTcpDefIdleTimeout and natConfTcpDefNegTimeout. > > 12) I suggest to reword the description of the TCP idle timeout > objects: > > natConfTcpDefIdleTimeout: > > The default time interval a NAT session (or is it a binding or > both?) for an established TCP connection is allowed to remain > valid without any activity on the TCP connection. > > natConfTcpDefNegTimeout: > > The default time interval a NAT session (or is it a binding or > both?) for a TCP connection which is not in the established state > is allowed to remain valid without any activity on the TCP > connection. > > The point here is that the phrase "TCP protocol session" confuses > me - do you refer to a NAT session for a TCP connection or > something else? > > 13) I fail to see how the notification thresholds actually work. It > seems to me that actually only the natConfAddrRiseThreshold is > used. If my reading is wrong, the text probably has to be > improved. > > 14) typo "... Groupn" -> "... Group" > > 15) The description of the natConfInterfaceTable should probably say > that this is per interface configuration (and then you can remove > the comment above ;-). > > 16) Why do you introduce natConfInterfaceIndex and not just import and > use ifIndex? > > 17) What are the semantics of zero-length natConfAddrMapConfigName > values? Can I actually have multiple natConfAddrMapConfigName > objects with the same value? If not, what happens if I try to > create them? And why do you identify address maps by name when all > the other entities are identified by numbers? > > Also, I find the description confusing since this does not > according to my understanding select a set of address maps but > rather a single address map. > > 18) The StorageType TC requires you to specify which objects are > writable if the storage type is permanent - see also section 4.6.4 > in the MIB review guidelines document. This is missing in all > places where StorageType is being used. > > 19) I fail to understand the concept of the OwnerId and GoupId. What > does the value 42 tell a management station? I think this concept > is important to introduce in the beginning of the document. > > 20) What precisely happens if I write a value != 0 to > natConfLocalPortFrom, natConfLocalPortTo, natConfGlobalPortFrom, > natConfGlobalPortTo on a basic NAT? > > 21) I think the number space for address binds (e.g. natAddrBindId, > natAddrPortBindId) should exclude the value 0. Perhaps it actually > makes sense to introduce TCs doe NatAddrBindId and > NatAddrBindIdOrZero so things will be consistent. > > 22) The description of natAddrBindDirection says: > > "This object represents the direction of the BIND. > A BIND may be either uni-directional or bi-directional, > same as the orientation of the address map, based on > which this bind is formed." > > Where in the address map is the direction specified? > > 23) Please say precisely which error is to be generated if you set > natAddrBindAddrMapName or natAddrPortBindAddrMapName to a non > existent addrMapName. > > 24) Should natAddrBindMaxIdleTime natAddrPortBindMaxIdleTime and > natSessionMaxIdleTime not use syntax TimeInterval instead of > TimeTicks? > > 25) You may want to rename all counters ending in *Translate to > *Translates to follow the old rules that counters are in plural. > > 26) The natAddrBindTable, natAddrPortBindTable and natSessionTable > have no StorageType, see the MIB review guidelines document. > > (In general, one can also ask why these tables are not part of the > configuration branch since I can do row creation here. Also there > are counters in the translation tables which are actually > statistics. Personally, I would just drop the branches since they > serve no real value and only increase the length of the OIDs.) > > 27) What is the "query id" you refer to in the description of > natAddrPortBindLocalPort and natAddrPortBindGlobalPort? If you > mean the ICMP type code, then please say ICMP type code. > > 28) In the number space for session, you really want to exclude the > value 0. Again, it might help to introduce specific TC(s). > > 29) What is the relationship between binds and sessions? Your MIB > is modelled as if it is 1:n, that is you can have n sessions > for one bind. Is that the case? > > 30) Is there redundant information? Can a session have a different > protocol type than the associated binds? Or why are > natSessionProtocolType and friends needed? > > 31) Looking at this description: > > natStatsAddrMapAddrUsed OBJECT-TYPE > SYNTAX Gauge32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of addresses, pertaining to this > address map, > that are currently being used from the nat pool. The > value of this object is irrelevant if the > address map in > question is a static address map." > ::= { natStatsAddrMapEntry 6 } > > What does it mean that the object is irrelevant? Should it still > be implemented (if not clarify in the compliance definition). If > implemented, should it still report the correct value or can it > contain arbitrary garbage? > > 32) I propose to rename the following objects for consistency: > > natStatsInterfacePktsIn -> natStatsInterfaceInTranslates > natStatsInterfacePktsOut -> natStatsInterfaceOutTranslates > > 33) I suggest to change the notification registration as follows: > > natMIBNotifications OBJECT IDENTIFIER ::= { natMIB 0 } > > natAddressUseRising NOTIFICATION-TYPE > -- yada yada > ::= { natMIBNotifications 1 } > > natPacketDiscard NOTIFICATION-TYPE > -- yada yada > ::= { natMIBNotifications 2 } > > > This again saves a sub-identifier and makes things more compact. > > 34) The description of natAddressUseRising makes me beliefe that the > falling threshold is actually never being used. > > 35) Why can you not use natConfAddrMapName instead of natAddrMapName > in the natPacketDiscard notification? And since you only > distinguish two discard reasons, why do you not simply use two > different notifications? This would avoid the introduction of > natPktDiscardReason. (In general, accessible-for-notify is kind of > a strange construction and this is why I wonder about these > objects.) > > 36) In the compliance section, you always talk about "MIDCOM > compliance" and I have no clue what that means. > > 37) I think there are dependencies between the natMIBNotif*Groups and > you probably want to spell them out since it does not make sense > to implement the natMIBNotificationGroup without the other > natMIBNotif*Groups. > > 38) I think section 9 is not really needed since this OID assignment > will happen automatically when this document is being processed. > > 39) In the security considerations, you simply state that "some of > these objects could contain sensitive information, e.g. bind > information". For someone deploying this, it might be useful to > have a more explicit discussion of the security implications. > > 40) Remove the leading quote character in teh Full Copyright Statement > section. > > That's it. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sun Sep 14 23:02:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24653 for ; Sun, 14 Sep 2003 23:02:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yjcs-0007rb-BL for midcom-archive@odin.ietf.org; Sun, 14 Sep 2003 23:02:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8F326eh030226 for midcom-archive@odin.ietf.org; Sun, 14 Sep 2003 23:02:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yjcn-0007qC-Ig; Sun, 14 Sep 2003 23:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yjcT-0007nw-6S for midcom@optimus.ietf.org; Sun, 14 Sep 2003 23:01:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24633 for ; Sun, 14 Sep 2003 23:01:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yjcP-0003wE-00 for midcom@ietf.org; Sun, 14 Sep 2003 23:01:37 -0400 Received: from web40407.mail.yahoo.com ([66.218.78.104]) by ietf-mx with smtp (Exim 4.12) id 19yjcO-0003tT-00 for midcom@ietf.org; Sun, 14 Sep 2003 23:01:36 -0400 Message-ID: <20030915030106.33274.qmail@web40407.mail.yahoo.com> Received: from [66.224.113.194] by web40407.mail.yahoo.com via HTTP; Sun, 14 Sep 2003 20:01:06 PDT Date: Sun, 14 Sep 2003 20:01:06 -0700 (PDT) From: Pyda Srisuresh To: "Wijnen, Bert \(Bert\)" , "'j.schoenwaelder@iu-bremen.de'" , rrohit74@hotmail.com, npai@cisco.com, raraghun@cisco.com, cliffwang2000@yahoo.com Cc: midcom@ietf.org In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15502331524@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [midcom] RE: NAT-MIB review Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Bert & Juergen, Please see my comments below. regards, suresh --- "Wijnen, Bert (Bert)" wrote: > Thanks Juergen. > So I expect the authors to respond/comment back, and to most > probably issue another revision to address the issues. > > Pls copy me explicitly on any follow up communication, cause > I am currently not subscribed to midcom list. > > Thanks, > Bert > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > > Sent: donderdag 11 september 2003 18:05 > > To: rrohit74@hotmail.com; npai@cisco.com; raraghun@cisco.com; > > cliffwang2000@yahoo.com; srisuresh@yahoo.com > > Cc: bwijnen@lucent.com; midcom@ietf.org > > Subject: NAT-MIB review > > > > > > Bert asked me to play the MIB doctor for the NAT-MIB and so I have > > reviewed . The document needs further > > editorial work in order to comply with the MIB guidelines as > > documented in and there > > are several technical questions that need to be discussed and resolved > > before the document is ready to go. > > Thanks, Juergen, for the detailed review. Great job indeed. You have really fine combed the syntax and semantics. Thansk again. I have responded to some below. For the remaining, I requested Rohit, one of my Co-authors, to chime in. However, any one of the co-authors might do so. A bunch of your questions relate to MIDCOM compliance. Unfortunately, the MidcomBase MIB is not published yet. Until the Midcombase MIB is out, the MIDCOM extension done in the NAT MIB would not make much sense to the readers, I am afraid. DO let me know if you have any suggestions on how to go about this. Thanks. > > 1) The abstract should not contain references, see also the > > guidelines > > document. > > Will do. > > 2) I suggest to add definitions of key terms into section 3. In > > particular, I would like to see a definition for concepts such > > as sessions, groups and probably owners. Also the relationship > > to other MIDCOM work needs to be explained since the MIB module > > talks about "MIDCOM compliance" and I have no clue what that > > means (see also below). > > OK. The Midcom compliance is pending a new Midcom draft outlining how SNMPv3 would suffice to serve as MIDCOM protocol. > > 3) In the overview section, you should say that this MIB module > > depends in some parts on the IF-MIB. > > Only in that NAT is configurable on a per-interface. We will mention this in the Overview section. Thanks. > > 4) In the overview section, please introduce the names of the tables > > and use these names where appropriate to reduce any risk for > > confusion. Some phrases I think are a bit confusing, e.g. > > > > o two scalars used to monitor address thresholds and generate > > notifications when the thresholds are crossed. > > > > I do not think you monitor thresholds. In fact, these thresholds > > define when notifications are generated. (And my later reading of > > the MIB makes me wonder whether the second one is ever used.) Perhaps Rohit will respond to this. > > > > 5) typo "... the currently exist ..." -> "... that currently > > exist ..." Yup. > > > > 6) Section 4.1 says: > > > > The association between the various configuration tables can be > > represented as follows: > > > > > > per interface config (global config parameters) > > | | > > | | > > | | > > |----------------------------| > > | > > | > > address map > > > > My understanding is that the global config parameters are just > > a few scalars and not a table. The diagram is correct. The configuration consists of a few global scalars (natConfig objects 1..7) and a per-interface address map(natConfInterfaceTable) > > > > 7) Section 4.3 says that binds which point to non-existing address > > maps are not allowed. In the MIB definitions, it would be very > > useful to say precisely what happens if one tries to violate the > > rule (that is, which error code is actually generated when I try > > to delete an address map with pending binds or try to create a > > bind which points to a non-existing address map). OK. When you try to delete an address map with pending binds, all associated BINDs are removed. No error is created. Typically, address maps are not edited once confgured.When you try to create a BIND pointing to a non-existing address map (or) an exisitng address map, but has no relevance to the BIND, BIND creation fails - error code: UnknownAddressMapEntry (or) InvalidAddressMapEntry. We will add this info. > > > > 8) You seem to use the RowStatus for two purposes - > > creating/destroying rows as well as enabling/disabling them. The > > compliance allows implementations that do only one-shot row > > creation and deletion, which means that those implementations > > do not have the capability to disable a row. Also note that a > > row in the notInService state has a timer attached so the row > > cannot be in that state for longer periods of time. > > > > Perhaps you want to introduce explicit enabled/disabled states for > > the rows in question in case it makes sense. Perhaps Rohit will respond to this. > > > > 9) The start of the module needs editorial work so that it conforms > > to section 4.5 in the MIB review guidelines document. OK. Perhaps Rohit will respond to this. > > > > 10) I suggest to also make the bit set representation of the protocol > > types an explicit TC so that both TCs are close together which > > reduces any maintenance issues. Agreed. Sounds good. > > > > 11) What does an idle timeout of 0 seconds actually mean? (This > > question affects natConfUdpDefIdleTimeout, > > natConfIcmpDefIdleTimeout, natConfOtherDefIdleTimeout, > > natConfTcpDefIdleTimeout and natConfTcpDefNegTimeout. When idle timeout is set to zero, these fields will be assigned their respective DEFVAL values. > > > > 12) I suggest to reword the description of the TCP idle timeout > > objects: > > > > natConfTcpDefIdleTimeout: > > > > The default time interval a NAT session (or is it a binding or > > both?) for an established TCP connection is allowed to remain > > valid without any activity on the TCP connection. OK. This refers just to the session, not the binding. > > > > natConfTcpDefNegTimeout: > > > > The default time interval a NAT session (or is it a binding or > > both?) for a TCP connection which is not in the established state > > is allowed to remain valid without any activity on the TCP > > connection. > > > > The point here is that the phrase "TCP protocol session" confuses > > me - do you refer to a NAT session for a TCP connection or > > something else? Yes. NAT session is for a TCP connection. Sorry about the confusing phrases. We will fix this. > > > > 13) I fail to see how the notification thresholds actually work. It > > seems to me that actually only the natConfAddrRiseThreshold is > > used. If my reading is wrong, the text probably has to be > > improved. Perhaps Rohit will respond to this. > > > > 14) typo "... Groupn" -> "... Group" OK. > > > > 15) The description of the natConfInterfaceTable should probably say > > that this is per interface configuration (and then you can remove > > the comment above ;-). The description in natConfInterfaceEntry does say this. But, could be clearer, perhaps. > > > > 16) Why do you introduce natConfInterfaceIndex and not just import and > > use ifIndex? Makes sense. perhaps Rohit will respond to this. > > > > 17) What are the semantics of zero-length natConfAddrMapConfigName > > values? A name with zero-length is invalid and has no impact. > > Can I actually have multiple natConfAddrMapConfigName > > objects with the same value? No. NatConfAddrMapTable indexed by natConfAddrMapName. > > If not, what happens if I try to > > create them? And why do you identify address maps by name when all > > the other entities are identified by numbers? Address map is essentially a file name with one or more address map entries within it. An interface is associated with a unique address map at the configuration time. As for the other entries identified by numbers - are you referign to Bind-Id, session-Id etc? These are NAt generated, so it makes sense for them to be a number. > > > > Also, I find the description confusing since this does not > > according to my understanding select a set of address maps but > > rather a single address map. Yes. You have just one address map selected per-interface. The actual address map entries associated with the name are obtained from natConfAddrMapTable. > > > > 18) The StorageType TC requires you to specify which objects are > > writable if the storage type is permanent - see also section 4.6.4 > > in the MIB review guidelines document. This is missing in all > > places where StorageType is being used. OK. Rohit wil lprobably address this. only natConfig & natConfAddrMapTable are saved between reboots. > > > > 19) I fail to understand the concept of the OwnerId and GoupId. What > > does the value 42 tell a management station? I think this concept > > is important to introduce in the beginning of the document. OK. The concept of Ownerid & GroupId are introduced principally to extend the MIB to be Midcom compliant. This will become apparent when the Midcom MIB draft is out. Essentially, a Midcombase MIB will maintain a table that associates Midcom agent (username) with the agentId assigned to it. Perhpa,s we could add a pointer to the midcombase MIB draft when the draft is published. The draft is currently in review by the design team. > > > > 20) What precisely happens if I write a value != 0 to > > natConfLocalPortFrom, natConfLocalPortTo, natConfGlobalPortFrom, > > natConfGlobalPortTo on a basic NAT? That would not be considered a BasicNat address map. As a result, this woudl not generate address BINDs. If the parameters donot fit the requirements of a static map or NAPT or one of the other supported maps, the address map entry will be declared invalid and will not be used. > > > > 21) I think the number space for address binds (e.g. natAddrBindId, > > natAddrPortBindId) should exclude the value 0. Perhaps it actually > > makes sense to introduce TCs doe NatAddrBindId and > > NatAddrBindIdOrZero so things will be consistent. OK. > > > > 22) The description of natAddrBindDirection says: > > > > "This object represents the direction of the BIND. > > A BIND may be either uni-directional or bi-directional, > > same as the orientation of the address map, based on > > which this bind is formed." > > > > Where in the address map is the direction specified? Good catch. We missed it. > > > > 23) Please say precisely which error is to be generated if you set > > natAddrBindAddrMapName or natAddrPortBindAddrMapName to a non > > existent addrMapName. For the NAT devices that are not MIDCOM compliant or donot communicate with MIDCOm agents, this is not an issue as the MAP name is generated by the NAT devices alone. In the case a NAT device is in session with a MIDCOM agent, INVALID_MAP_NAME error will be issued when the specified MapName is invalid. > > > > 24) Should natAddrBindMaxIdleTime natAddrPortBindMaxIdleTime and > > natSessionMaxIdleTime not use syntax TimeInterval instead of > > TimeTicks? Perhaps Rohit will respond to this. > > > > 25) You may want to rename all counters ending in *Translate to > > *Translates to follow the old rules that counters are in plural. OK. > > > > 26) The natAddrBindTable, natAddrPortBindTable and natSessionTable > > have no StorageType, see the MIB review guidelines document. > > > > (In general, one can also ask why these tables are not part of the > > configuration branch since I can do row creation here. Also there > > are counters in the translation tables which are actually > > statistics. Personally, I would just drop the branches since they > > serve no real value and only increase the length of the OIDs.) natAddrBindTable, natAddrPortBindTable and natSessionTable are genrated dynamically by the NAt device and are not saved between reboots. Unlike these, natConfig is a configuration object. Perhaps, Rohit will respond to this in detail. > > > > 27) What is the "query id" you refer to in the description of > > natAddrPortBindLocalPort and natAddrPortBindGlobalPort? If you > > mean the ICMP type code, then please say ICMP type code. This is refering to the Identifier field in the header. > > > > 28) In the number space for session, you really want to exclude the > > value 0. Again, it might help to introduce specific TC(s). OK. > > > > 29) What is the relationship between binds and sessions? Your MIB > > is modelled as if it is 1:n, that is you can have n sessions > > for one bind. Is that the case? Yes. > > > > 30) Is there redundant information? Can a session have a different > > protocol type than the associated binds? Or why are > > natSessionProtocolType and friends needed? Well, session desribes the full session characteristics - namely the original 5-tuple and the xlated 5-tuple. When a session has a non-zero BindId specified, the ProtocolType and friends in the session must match that of the BIND. However, in case of a symmetric NAPT device, the Session will have BindId specified as Zero. In such a case, the session must include AddressMapName and AddressMapEntryIndex specified. Oops... these two fields are missing in NatSessionEntry. > > > > 31) Looking at this description: > > > > natStatsAddrMapAddrUsed OBJECT-TYPE > > SYNTAX Gauge32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The number of addresses, pertaining to this > > address map, > > that are currently being used from the nat pool. The > > value of this object is irrelevant if the > > address map in > > question is a static address map." > > ::= { natStatsAddrMapEntry 6 } > > > > What does it mean that the object is irrelevant? Should it still > > be implemented (if not clarify in the compliance definition). If > > implemented, should it still report the correct value or can it > > contain arbitrary garbage? Perhaps Rohit will address this in detail. But, here is my read on this. In the case of static address map, this could will be the full count of all addresses that are statically mapped. There is no room for additional addresses for performing a BIND. > > > > 32) I propose to rename the following objects for consistency: > > > > natStatsInterfacePktsIn -> natStatsInterfaceInTranslates > > natStatsInterfacePktsOut -> natStatsInterfaceOutTranslates Sounds good. > > > > 33) I suggest to change the notification registration as follows: > > > > natMIBNotifications OBJECT IDENTIFIER ::= { natMIB 0 } > > > > natAddressUseRising NOTIFICATION-TYPE > > -- yada yada > > ::= { natMIBNotifications 1 } > > > > natPacketDiscard NOTIFICATION-TYPE > > -- yada yada > > ::= { natMIBNotifications 2 } > > > > > > This again saves a sub-identifier and makes things more compact. > > > > 34) The description of natAddressUseRising makes me beliefe that the > > falling threshold is actually never being used > > > > 35) Why can you not use natConfAddrMapName instead of natAddrMapName > > in the natPacketDiscard notification? And since you only > > distinguish two discard reasons, why do you not simply use two > > different notifications? This would avoid the introduction of > > natPktDiscardReason. (In general, accessible-for-notify is kind of > > a strange construction and this is why I wonder about these > > objects.) Perhaps, Rohit will respond to the above three. > > > > 36) In the compliance section, you always talk about "MIDCOM > > compliance" and I have no clue what that means. How do you suggest we break the umbilical chord? I agree, much of this has no meaning unless the Midcom-MIB is published. > > > > 37) I think there are dependencies between the natMIBNotif*Groups and > > you probably want to spell them out since it does not make sense > > to implement the natMIBNotificationGroup without the other > > natMIBNotif*Groups. perhaps Rohit will respond to this. > > > > 38) I think section 9 is not really needed since this OID assignment > > will happen automatically when this document is being processed. OK. > > > > 39) In the security considerations, you simply state that "some of > > these objects could contain sensitive information, e.g. bind > > information". For someone deploying this, it might be useful to > > have a more explicit discussion of the security implications. Perhaps, this will make more sense when the Midcom MIB is reviewed and published. The objective of the Midcom MIB is to ensure that only the authorized agents are allowed to modify the NAT resources; And, SNMPv3 ishall be the management protocol. > > > > 40) Remove the leading quote character in teh Full Copyright Statement > > section. OK. > > > > That's it. > > > > /js > > > > -- > > Juergen Schoenwaelder International University Bremen > > P.O. Box 750 561, > > 28725 Bremen, Germany > > ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Sep 15 10:46:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05483 for ; Mon, 15 Sep 2003 10:46:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yucE-0001iF-Tr for midcom-archive@odin.ietf.org; Mon, 15 Sep 2003 10:46:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FEkADm006579 for midcom-archive@odin.ietf.org; Mon, 15 Sep 2003 10:46:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yuc6-0001gn-F6; Mon, 15 Sep 2003 10:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ymTC-0002mb-Lf for midcom@optimus.ietf.org; Mon, 15 Sep 2003 02:04:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03310 for ; Mon, 15 Sep 2003 02:04:11 -0400 (EDT) From: Rohit.Mehendiratta@utstar.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ymT8-0004zH-00 for midcom@ietf.org; Mon, 15 Sep 2003 02:04:14 -0400 Received: from quartz.mw.3com.com ([192.65.73.145]) by ietf-mx with esmtp (Exim 4.12) id 19ymT8-0004tF-00 for midcom@ietf.org; Mon, 15 Sep 2003 02:04:14 -0400 Received: from gypsum.mw.3com.com (gypsum.mw.3com.com [149.112.20.3]) by quartz.mw.3com.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h8F68WfH025059; Sun, 14 Sep 2003 23:08:33 -0700 (PDT) Received: from utstarchi01.mw.3com.com (uschi001.mw.3com.com [149.112.142.9]) by gypsum.mw.3com.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h8F63hNl025946; Sun, 14 Sep 2003 23:03:43 -0700 (PDT) To: bwijnen@lucent.com, j.schoenwaelder@iu-bremen.de Cc: npai@cisco.com, raraghun@cisco.com, srisuresh@yahoo.com, cliffwang2000@yahoo.com, midcom@ietf.org, rrohit74@hotmail.com Date: Mon, 15 Sep 2003 01:02:56 -0500 Message-ID: X-MIMETrack: Serialize by Router on UTSTARCHI01/UTStarcom(Release 5.0.12 |February 13, 2003) at 09/15/2003 01:03:00 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [midcom] Re: Fwd: RE: NAT-MIB review Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Juergen, Thanks a lot for your comments. It looks like that we will have to come up with a new revision to address most of your comments. I agree with most of your comments. I will only list the comments here, where i have some confusion/explanation to make. 1. As Suresh also mentioned that Midcom MIB is not published yet; thats why MIDCOM Compliance/Owner Id/Group Id may not make much sense. What should we do in this case ? 2. > > > > > > 7) Section 4.3 says that binds which point to non-existing address > > > maps are not allowed. In the MIB definitions, it would be very > > > useful to say precisely what happens if one tries to violate the > > > rule (that is, which error code is actually generated when I try > > > to delete an address map with pending binds or try to create a > > > bind which points to a non-existing address map). In the last revision, i had mentioned snmp error code as inconsistentErrorValue but there were comments that this error code is only specific to some snmp version and hence we shouldn't mention it. I would like to know your opinion on the same. 3. I will remove storageType objects on the next version as i don't see much use of them in this MIB. Let me know your opinion about the same. 4. It is my undretstaning that in most of the customer scenarios, the binds and sessions are generated dynamically while addrmaps are configured. Thats why we have separate branches for config and translation. Even if the bind and session have the rowStatus, i don't anticipate it to be used widely. 5. Related to notification changes, we will simplify it a lot in the next version. Thanks Rohit >From: Pyda Srisuresh >To: "Wijnen, Bert \(Bert\)" , >"'j.schoenwaelder@iu-bremen.de'" , >rrohit74@hotmail.com, npai@cisco.com, raraghun@cisco.com, >cliffwang2000@yahoo.com >CC: midcom@ietf.org >Subject: RE: NAT-MIB review >Date: Sun, 14 Sep 2003 20:01:06 -0700 (PDT) > >Bert & Juergen, > >Please see my comments below. > >regards, >suresh > >--- "Wijnen, Bert (Bert)" wrote: > > Thanks Juergen. > > So I expect the authors to respond/comment back, and to most > > probably issue another revision to address the issues. > > > > Pls copy me explicitly on any follow up communication, cause > > I am currently not subscribed to midcom list. > > > > Thanks, > > Bert > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > > > Sent: donderdag 11 september 2003 18:05 > > > To: rrohit74@hotmail.com; npai@cisco.com; raraghun@cisco.com; > > > cliffwang2000@yahoo.com; srisuresh@yahoo.com > > > Cc: bwijnen@lucent.com; midcom@ietf.org > > > Subject: NAT-MIB review > > > > > > > > > Bert asked me to play the MIB doctor for the NAT-MIB and so I have > > > reviewed . The document needs further > > > editorial work in order to comply with the MIB guidelines as > > > documented in and there > > > are several technical questions that need to be discussed and resolved > > > before the document is ready to go. > > > >Thanks, Juergen, for the detailed review. Great job indeed. You have really >fine combed the syntax and semantics. Thansk again. I have responded to >some >below. For the remaining, I requested Rohit, one of my Co-authors, to chime >in. >However, any one of the co-authors might do so. > >A bunch of your questions relate to MIDCOM compliance. Unfortunately, the >MidcomBase MIB is not published yet. Until the Midcombase MIB is out, the >MIDCOM extension done in the NAT MIB would not make much sense to the >readers, >I am afraid. DO let me know if you have any suggestions on how to go about >this. Thanks. > > > > > 1) The abstract should not contain references, see also the > > > guidelines > > > document. > > > > >Will do. > > > > 2) I suggest to add definitions of key terms into section 3. In > > > particular, I would like to see a definition for concepts such > > > as sessions, groups and probably owners. Also the relationship > > > to other MIDCOM work needs to be explained since the MIB module > > > talks about "MIDCOM compliance" and I have no clue what that > > > means (see also below). > > > > >OK. The Midcom compliance is pending a new Midcom draft outlining how >SNMPv3 >would suffice to serve as MIDCOM protocol. > > > > 3) In the overview section, you should say that this MIB module > > > depends in some parts on the IF-MIB. > > > > >Only in that NAT is configurable on a per-interface. We will mention this >in >the Overview section. Thanks. > > > > 4) In the overview section, please introduce the names of the tables > > > and use these names where appropriate to reduce any risk for > > > confusion. Some phrases I think are a bit confusing, e.g. > > > > > > o two scalars used to monitor address thresholds and generate > > > notifications when the thresholds are crossed. > > > > > > I do not think you monitor thresholds. In fact, these thresholds > > > define when notifications are generated. (And my later reading of > > > the MIB makes me wonder whether the second one is ever used.) > >Perhaps Rohit will respond to this. [ROHIT] will do this. > > > > > > > 5) typo "... the currently exist ..." -> "... that currently > > > exist ..." >Yup. > > > > > > > 6) Section 4.1 says: > > > > > > The association between the various configuration tables can be > > > represented as follows: > > > > > > > > > per interface config (global config parameters) > > > | | > > > | | > > > | | > > > |----------------------------| > > > | > > > | > > > address map > > > > > > My understanding is that the global config parameters are just > > > a few scalars and not a table. > >The diagram is correct. The configuration consists of a few global scalars >(natConfig objects 1..7) and a per-interface address >map(natConfInterfaceTable) > > > > > > > > 7) Section 4.3 says that binds which point to non-existing address > > > maps are not allowed. In the MIB definitions, it would be very > > > useful to say precisely what happens if one tries to violate the > > > rule (that is, which error code is actually generated when I try > > > to delete an address map with pending binds or try to create a > > > bind which points to a non-existing address map). >OK. When you try to delete an address map with pending binds, all >associated >BINDs are removed. No error is created. Typically, address maps are not >edited >once confgured.When you try to create a BIND pointing to a non-existing >address >map (or) an exisitng address map, but has no relevance to the BIND, BIND >creation fails - error code: UnknownAddressMapEntry (or) >InvalidAddressMapEntry. > >We will add this info. > > > > > > 8) You seem to use the RowStatus for two purposes - > > > creating/destroying rows as well as enabling/disabling them. The > > > compliance allows implementations that do only one-shot row > > > creation and deletion, which means that those implementations > > > do not have the capability to disable a row. Also note that a > > > row in the notInService state has a timer attached so the row > > > cannot be in that state for longer periods of time. > > > > > > Perhaps you want to introduce explicit enabled/disabled states for > > > the rows in question in case it makes sense. > >Perhaps Rohit will respond to this. > > > > > > > 9) The start of the module needs editorial work so that it conforms > > > to section 4.5 in the MIB review guidelines document. > >OK. Perhaps Rohit will respond to this. > > > > > > > 10) I suggest to also make the bit set representation of the protocol > > > types an explicit TC so that both TCs are close together which > > > reduces any maintenance issues. > >Agreed. Sounds good. > > > > > > > 11) What does an idle timeout of 0 seconds actually mean? (This > > > question affects natConfUdpDefIdleTimeout, > > > natConfIcmpDefIdleTimeout, natConfOtherDefIdleTimeout, > > > natConfTcpDefIdleTimeout and natConfTcpDefNegTimeout. > >When idle timeout is set to zero, these fields will be assigned their >respective DEFVAL values. > > > > > > 12) I suggest to reword the description of the TCP idle timeout > > > objects: > > > > > > natConfTcpDefIdleTimeout: > > > > > > The default time interval a NAT session (or is it a binding or > > > both?) for an established TCP connection is allowed to remain > > > valid without any activity on the TCP connection. > >OK. This refers just to the session, not the binding. > > > > > > > natConfTcpDefNegTimeout: > > > > > > The default time interval a NAT session (or is it a binding or > > > both?) for a TCP connection which is not in the established state > > > is allowed to remain valid without any activity on the TCP > > > connection. > > > > > > The point here is that the phrase "TCP protocol session" confuses > > > me - do you refer to a NAT session for a TCP connection or > > > something else? > >Yes. NAT session is for a TCP connection. Sorry about the confusing >phrases. >We will fix this. > > > > > > > 13) I fail to see how the notification thresholds actually work. It > > > seems to me that actually only the natConfAddrRiseThreshold is > > > used. If my reading is wrong, the text probably has to be > > > improved. >Perhaps Rohit will respond to this. > > > > > > > 14) typo "... Groupn" -> "... Group" >OK. > > > > > > > 15) The description of the natConfInterfaceTable should probably say > > > that this is per interface configuration (and then you can remove > > > the comment above ;-). >The description in natConfInterfaceEntry does say this. But, could be >clearer, >perhaps. > > > > > > > 16) Why do you introduce natConfInterfaceIndex and not just import and > > > use ifIndex? > >Makes sense. perhaps Rohit will respond to this. > > > > > > 17) What are the semantics of zero-length natConfAddrMapConfigName > > > values? > >A name with zero-length is invalid and has no impact. > > > > Can I actually have multiple natConfAddrMapConfigName > > > objects with the same value? >No. NatConfAddrMapTable indexed by natConfAddrMapName. > > > > If not, what happens if I try to > > > create them? And why do you identify address maps by name when all > > > the other entities are identified by numbers? > >Address map is essentially a file name with one or more address map entries >within it. An interface is associated with a unique address map at the >configuration time. > >As for the other entries identified by numbers - are you referign to >Bind-Id, >session-Id etc? These are NAt generated, so it makes sense for them to be a >number. > > > > > > Also, I find the description confusing since this does not > > > according to my understanding select a set of address maps but > > > rather a single address map. > >Yes. You have just one address map selected per-interface. The actual >address >map entries associated with the name are obtained from natConfAddrMapTable. > > > > > > > 18) The StorageType TC requires you to specify which objects are > > > writable if the storage type is permanent - see also section 4.6.4 > > > in the MIB review guidelines document. This is missing in all > > > places where StorageType is being used. > >OK. Rohit wil lprobably address this. >only natConfig & natConfAddrMapTable are saved between reboots. > > > > > > > 19) I fail to understand the concept of the OwnerId and GoupId. What > > > does the value 42 tell a management station? I think this concept > > > is important to introduce in the beginning of the document. > >OK. The concept of Ownerid & GroupId are introduced principally to extend >the >MIB to be Midcom compliant. This will become apparent when the Midcom MIB >draft >is out. > >Essentially, a Midcombase MIB will maintain a table that associates Midcom >agent (username) with the agentId assigned to it. Perhpa,s we could add a >pointer to the midcombase MIB draft when the draft is published. The draft >is >currently in review by the design team. > > > > > > > 20) What precisely happens if I write a value != 0 to > > > natConfLocalPortFrom, natConfLocalPortTo, natConfGlobalPortFrom, > > > natConfGlobalPortTo on a basic NAT? > >That would not be considered a BasicNat address map. As a result, this >woudl >not generate address BINDs. If the parameters donot fit the requirements of >a >static map or NAPT or one of the other supported maps, the address map >entry >will be declared invalid and will not be used. > > > > > > 21) I think the number space for address binds (e.g. natAddrBindId, > > > natAddrPortBindId) should exclude the value 0. Perhaps it actually > > > makes sense to introduce TCs doe NatAddrBindId and > > > NatAddrBindIdOrZero so things will be consistent. >OK. > > > > > > > 22) The description of natAddrBindDirection says: > > > > > > "This object represents the direction of the BIND. > > > A BIND may be either uni-directional or bi-directional, > > > same as the orientation of the address map, based on > > > which this bind is formed." > > > > > > Where in the address map is the direction specified? >Good catch. We missed it. > > > > > > > 23) Please say precisely which error is to be generated if you set > > > natAddrBindAddrMapName or natAddrPortBindAddrMapName to a non > > > existent addrMapName. > >For the NAT devices that are not MIDCOM compliant or donot communicate with >MIDCOm agents, this is not an issue as the MAP name is generated by the NAT >devices alone. > >In the case a NAT device is in session with a MIDCOM agent, >INVALID_MAP_NAME >error will be issued when the specified MapName is invalid. > > > > > > > 24) Should natAddrBindMaxIdleTime natAddrPortBindMaxIdleTime and > > > natSessionMaxIdleTime not use syntax TimeInterval instead of > > > TimeTicks? > >Perhaps Rohit will respond to this. > > > > > > > 25) You may want to rename all counters ending in *Translate to > > > *Translates to follow the old rules that counters are in plural. >OK. > > > > > > > 26) The natAddrBindTable, natAddrPortBindTable and natSessionTable > > > have no StorageType, see the MIB review guidelines document. > > > > > > (In general, one can also ask why these tables are not part of the > > > configuration branch since I can do row creation here. Also there > > > are counters in the translation tables which are actually > > > statistics. Personally, I would just drop the branches since they > > > serve no real value and only increase the length of the OIDs.) > >natAddrBindTable, natAddrPortBindTable and natSessionTable are genrated >dynamically by the NAt device and are not saved between reboots. Unlike >these, >natConfig is a configuration object. > >Perhaps, Rohit will respond to this in detail. > > > > > > 27) What is the "query id" you refer to in the description of > > > natAddrPortBindLocalPort and natAddrPortBindGlobalPort? If you > > > mean the ICMP type code, then please say ICMP type code. > >This is refering to the Identifier field in the header. > > > > > > > 28) In the number space for session, you really want to exclude the > > > value 0. Again, it might help to introduce specific TC(s). >OK. > > > > > > > 29) What is the relationship between binds and sessions? Your MIB > > > is modelled as if it is 1:n, that is you can have n sessions > > > for one bind. Is that the case? >Yes. > > > > > > > 30) Is there redundant information? Can a session have a different > > > protocol type than the associated binds? Or why are > > > natSessionProtocolType and friends needed? > >Well, session desribes the full session characteristics - namely the >original >5-tuple and the xlated 5-tuple. When a session has a non-zero BindId >specified, >the ProtocolType and friends in the session must match that of the BIND. >However, in case of a symmetric NAPT device, the Session will have BindId >specified as Zero. In such a case, the session must include AddressMapName >and >AddressMapEntryIndex specified. Oops... these two fields are missing in >NatSessionEntry. > > > > > > > > 31) Looking at this description: > > > > > > natStatsAddrMapAddrUsed OBJECT-TYPE > > > SYNTAX Gauge32 > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION > > > "The number of addresses, pertaining to this > > > address map, > > > that are currently being used from the nat pool. The > > > value of this object is irrelevant if the > > > address map in > > > question is a static address map." > > > ::= { natStatsAddrMapEntry 6 } > > > > > > What does it mean that the object is irrelevant? Should it still > > > be implemented (if not clarify in the compliance definition). If > > > implemented, should it still report the correct value or can it > > > contain arbitrary garbage? > >Perhaps Rohit will address this in detail. >But, here is my read on this. In the case of static address map, this could >will be the full count of all addresses that are statically mapped. There >is no >room for additional addresses for performing a BIND. > > > > > > > > 32) I propose to rename the following objects for consistency: > > > > > > natStatsInterfacePktsIn -> natStatsInterfaceInTranslates > > > natStatsInterfacePktsOut -> natStatsInterfaceOutTranslates >Sounds good. > > > > > > > 33) I suggest to change the notification registration as follows: > > > > > > natMIBNotifications OBJECT IDENTIFIER ::= { natMIB 0 } > > > > > > natAddressUseRising NOTIFICATION-TYPE > > > -- yada yada > > > ::= { natMIBNotifications 1 } > > > > > > natPacketDiscard NOTIFICATION-TYPE > > > -- yada yada > > > ::= { natMIBNotifications 2 } > > > > > > > > > This again saves a sub-identifier and makes things more compact. > > > > > > 34) The description of natAddressUseRising makes me beliefe that the > > > falling threshold is actually never being used > > > > > > 35) Why can you not use natConfAddrMapName instead of natAddrMapName > > > in the natPacketDiscard notification? And since you only > > > distinguish two discard reasons, why do you not simply use two > > > different notifications? This would avoid the introduction of > > > natPktDiscardReason. (In general, accessible-for-notify is kind of > > > a strange construction and this is why I wonder about these > > > objects.) > >Perhaps, Rohit will respond to the above three. > > > > > > > 36) In the compliance section, you always talk about "MIDCOM > > > compliance" and I have no clue what that means. > >How do you suggest we break the umbilical chord? I agree, much of this has >no >meaning unless the Midcom-MIB is published. > > > > > > > 37) I think there are dependencies between the natMIBNotif*Groups and > > > you probably want to spell them out since it does not make sense > > > to implement the natMIBNotificationGroup without the other > > > natMIBNotif*Groups. > >perhaps Rohit will respond to this. > > > > > > > 38) I think section 9 is not really needed since this OID assignment > > > will happen automatically when this document is being processed. >OK. > > > > > > > 39) In the security considerations, you simply state that "some of > > > these objects could contain sensitive information, e.g. bind > > > information". For someone deploying this, it might be useful to > > > have a more explicit discussion of the security implications. > >Perhaps, this will make more sense when the Midcom MIB is reviewed and >published. The objective of the Midcom MIB is to ensure that only the >authorized agents are allowed to modify the NAT resources; And, SNMPv3 >ishall >be the management protocol. > > > > > > > 40) Remove the leading quote character in teh Full Copyright Statement > > > section. >OK. > > > > > > > That's it. > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder International University Bremen > > > P.O. Box 750 561, > > > 28725 Bremen, Germany > > > > > >===== > _________________________________________________________________ MSN Hotmail now on your Mobile phone. http://server1.msn.co.in/sp03/mobilesms/ Click here. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Sep 15 11:08:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06239 for ; Mon, 15 Sep 2003 11:08:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yuxQ-0004GB-FB for midcom-archive@odin.ietf.org; Mon, 15 Sep 2003 11:08:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FF841o016362 for midcom-archive@odin.ietf.org; Mon, 15 Sep 2003 11:08:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yuxO-0004F5-9D; Mon, 15 Sep 2003 11:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yuwu-00044v-4j for midcom@optimus.ietf.org; Mon, 15 Sep 2003 11:07:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06211 for ; Mon, 15 Sep 2003 11:07:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yuwr-0000mm-00 for midcom@ietf.org; Mon, 15 Sep 2003 11:07:29 -0400 Received: from web40407.mail.yahoo.com ([66.218.78.104]) by ietf-mx with smtp (Exim 4.12) id 19yuwq-0000kJ-00 for midcom@ietf.org; Mon, 15 Sep 2003 11:07:28 -0400 Message-ID: <20030915150658.43842.qmail@web40407.mail.yahoo.com> Received: from [67.164.29.130] by web40407.mail.yahoo.com via HTTP; Mon, 15 Sep 2003 08:06:58 PDT Date: Mon, 15 Sep 2003 08:06:58 -0700 (PDT) From: Pyda Srisuresh Subject: was: Re: [midcom] Reminder: wg last call To: "Jürgen_Quittek" , Daniel Fonseca , midcom@ietf.org In-Reply-To: <2147483647.1063291117@[10.1.1.171]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA06212 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable --- J=FCrgen_Quittek wrote: > Daniel, >=20 > Thank you very much for all your comments. >=20 > Most of them are very helpful and we will apply them. > Please see detailed replies inline. >=20 <... stuff deleted> >=20 > > Page 10, "- internal IP address wildcard support > > - external IP address wildcard support" > > (I believe this has been mentioned recently in the > > list) > > It is very common for middlebox-ish devices to have > > more than two interfaces. How is midcom going to > > handle that? Shouldn't there be an interface-id? This > > involves many other sections in the text. >=20 > In the MIDCOM information model there is just an internal > (protected, private, ...) network and and external (public?) > network. How many interfaces of a middlebox are connected to > which of these two networks is not of interest to applications > requesting the box to just ENABLE communication between two > specified end points. Which interfaces are involved in serving > such a request needs to be identified by the middlebox internally. >=20 Juergen - If you have several interfaces on the private realm and a inter= face on the public relam, you might choose to have NAT/FW configured on just t= he public interface. No problem with that. It is OK to use an information mo= del a describe a theory of operation. But, the model cannot be imposed as is on= the middleboxes. A middlebox may be attached to several overlapping private networks. A middlebox may also have several public interfaces (combinatio= n of V4 and v6). For these reasons, a middlebox must be configurable on a per-interface basis. <.. stuff deleted> =3D=3D=3D=3D=3D _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Sep 15 12:34:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10686 for ; Mon, 15 Sep 2003 12:34:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ywIe-0006VQ-DL for midcom-archive@odin.ietf.org; Mon, 15 Sep 2003 12:34:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FGY4ZR025005 for midcom-archive@odin.ietf.org; Mon, 15 Sep 2003 12:34:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ywIb-0006Uh-RZ; Mon, 15 Sep 2003 12:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ywHp-0006Q0-2v for midcom@optimus.ietf.org; Mon, 15 Sep 2003 12:33:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10610 for ; Mon, 15 Sep 2003 12:33:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ywHn-000171-00 for midcom@ietf.org; Mon, 15 Sep 2003 12:33:11 -0400 Received: from web40411.mail.yahoo.com ([66.218.78.108]) by ietf-mx with smtp (Exim 4.12) id 19ywHm-00013v-00 for midcom@ietf.org; Mon, 15 Sep 2003 12:33:10 -0400 Message-ID: <20030915163239.92743.qmail@web40411.mail.yahoo.com> Received: from [67.164.29.130] by web40411.mail.yahoo.com via HTTP; Mon, 15 Sep 2003 09:32:39 PDT Date: Mon, 15 Sep 2003 09:32:39 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Reminder: wg last call To: "Jürgen_Quittek" , midcom@ietf.org Cc: stiemerling@ccrle.nec.de, taylor@nortelnetworks.com In-Reply-To: <2147483647.1063288853@[10.1.1.171]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA10611 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Jurgen, Please see my comments below. regards, suresh --- J=FCrgen_Quittek wrote: > Pyda, >=20 > Thanks for your comments. Please see replies to some of them inline. >=20 > --On 06.09.2003 14:15 Uhr -0700 Pyda Srisuresh wr= ote: >=20 > > Below is text of the e-mail (a little revised) I sent to the authors > earlier. I > > am including the text for wider audience. Below are my outstanding co= mments > on > > the draft. > > > > 1. For a NAT middlebox, I believe, the semantics ought to cover the > following > > transactions. My comments assume the following. > > > > A. NAT is configured on a per-interface basis. As such, the > > Midcom/NAT transactions would be specified on a per-interfac= e > basis. >=20 > I do not share this view. A midcom agent has the intention and capabili= ty > to specify endpoints of communication across the middlebox. Which inter= faces > of the middlebox are affected is not subject of midcom transactions. It would be when the middlebox has several interfaces. >=20 > The MIDCOM information model simplifies the network view by just separa= ting > an internal network and an external network. Whether or not the middleb= ox has > one or more interfaces connected to any of them is considered an intern= al > matter > of the middlebox. The above argument would suffice for an information model where the netwo= rk view is merely in terms of an internal network and an external network. T= his would not be adequate on an operating middlebox. Both NAT and firewall of= tne have interface specific configurations. midcom agent will have all the information it needs from the middlebox using per-intarface configuration= s. =20 >=20 > There is no statement in framework or requirements that oblige an agent= to > find > out which interfaces a middlebox is using. >=20 The above two documents are agnostic to the deployment scenarios and do n= ot assume a specific type of middlebox or network configurations.=20 > > B. End-point below is to be refered as > > for a PortBind. End-point for an address Bind will be > > . The IP address can be V4 or V6. > > C. The transactions specified below can be applicable to one or= more > > end-points. This will include address ranges, address > > wild-carding, port ranges, and port wild-carding. > > > > > > SetMapOwner [Full | Partial] [] > > - SetMapowner may be used by an agent to claim > > ownership on a complete NAT map entry or a > > portion of the entry. AgentId will be set as = the > > owner of the entire map entry or portion ther= eof. > > > > (CreateBind | CreatePortBind) > > > > - Agent specifies all the requisite Parameters = for > > Bind(s) or PortBind(s). Agent requests middle= box > > to create a BIND and respond back with an ass= igned > > BindId. Middlebox to validate the authorizati= on > > prior to responding. > > > > (RequestCreateBind | RequestPortCreateBind) > > [Oddity option= ] > > - Agent requests the Middlebox to create BIND(s= ) for > > the given End-point, optionally with an Oddit= y > > requirement. Middlebox to validate the > > authorization, prior to assgining a BIND and > > a BindId and returning the response. > > > > CreateOutboundSession > > | > > | > > > > > > - Agent specifies all the requisite Parameters = for > > an outbound session. Agent requests middlebox > > to create a session as specified and respond = back > > with an assigned BindId. > > The session may have one or two end-point > > translations. The session may be derived dire= ctly > > from the address map (or) from associated Bin= d-IDs. > > Middlebox to validate the authorization prior= to > > responding. Note, the session tuple may have > > wild-card elements. > > > > RequestCreateOutboundSession > > | > > | > > > > - Agent requests the Middlebox to create an out= bound > > session for the given session tuple, using on= e or > > more map entries and/or end-point BINDs. Agen= t > > to validate he authorization prior to respond= ing > > back with a new session and session-id. As be= fore, > > the session tuple may have wild-card elements. > > > > CreateInboundSession, > > RequestCreateInboundSession > > - Similar to the outbound counterparts. > > > > ModifyBindParameters > > [] [MaximumIdletime>] [] > > - These parameters may be specified either at B= ind > > creation time or later. > > > > ModifySessionParameters > > [] [MaximumIdletime>] [] > > - These parameters may be specified either at s= ession > > creation time or later. Note, session here re= fers > > to the NAT data sessions, not the Midcom agen= t > > session. > > > > In particular, I would like to mention the notion of three resources > > a NAT middlebox and midcom agent need to be cognizant of - > > Address map entries, Binds and sessions. These resources may be a) cr= eated > by > > the agent, b) created by the NAT middlebox, or c) paramaters modified= by > the > > agent. >=20 > The way I see it, MIDCOM does not distinguish binding and session (as t= he NAT > MIB does). Why is that? Binds and sessions must be distinguished. This is nothign ne= w. You might want to refer RFC 3489 as to why it is important to make this disti= nction n the context of NAPT devices. > The point is that the MIDCOM protocol is not a middlebox management pro= tocol, > but a > protocol that allows applications to express requests for enabling > communication > across a middlebox. Agreed. But, you cannot mandate that a middlebox to support requests that= it is not capable of. Ex: If an agent creates a port-Bind-ID and expects this B= ind-Id to be used for all outgoign sessions by the NAPT device, the agent is goi= ng to be disappointed on certain boxes.=20 =20 >=20 > > 2. The notion of PRR is incomplete without the context of the entire > address > > map entry. The reservation may not be specific to address/address-por= t > alone. > > My view of this is simply that PRR is just another notion of ownershi= p > claim. > > it just happens to be in relation to an address map entry. >=20 > The intention behind PRR is just to reserve addresses at the middlebox. > This can be doen without mapping them already. Jurgen - A middlebox may have several address map entries configured on a= n interface. Which of the entries do you refer the addresses to? Why do you= think the agent shoudl be allowed to reserve addresses alone? >=20 > > 3. When you combine the notion of PRR wth PER, the state transition d= iagram > in > > section 2.3.13 woudl be simplified, with the proviso that there would= be > three > > types of policy rules (address map entries, binds and sessions). >=20 > Again, binds and sessions cannot be distinguished in the midcom world. Again, this is not true. Can you point me to any reference that said this= ? >=20 > > 4. I agree with your notion of Session establishment and session > termination > > transactions. > > > > 5. I believe, the group Ids an agent would use during the lifetime of= a > Midcom > > session should be specified by the agent - either at the midcom sessi= on > > establishment time or afterwards whild the midcom session is alive. G= iven > that > > group-Ids are specific to an agent, it shoudl be agent's responsibili= ty to > > assign group IDs, not that of the middlebox's. Further, given that th= ere > are 3 >=20 > Group IDs need to be unique per middlebox. Why is that? Groups are a convenience concept introduced for the benefit = of agents and hence are relevant to midcom agents. Agents use Group Ids to p= rocess a group of resources in a unique way. As such, the midcom agents ought to= be able to select groupIds unique to itself. I donot see a reason why the uniqueness of the following tuple not be adequate? (AgentId, MiddleboxFunctionResourceType, GroupId).=20 > This is hard to achieve if the agent assigns them. On the contrary, I believe the opposite. Please see my note above. >=20 > > different types of resources (map entries, Binds and sessions), there > shoudl be > > three different sets of group-Ids, one set for each resource type. > > Middlebox will assign a default groupId of 0 to all entities that are= not > > assigned a groupId by the agent. >=20 > I prefer to have reservation rules and enable rules (bindings) to be > able to share a group.=20 Why do you need reservation rules to be able to share a group? I find the reservation concept alien to NAT middleboxes. Are you talking about trans= fer of ownership from an address map entry to BINDs? if so, I dont see that as problem. If not, I donot know what you are talking about. > because then the agent can extend or delete > sets of them belonging together by just accessing a single group. I have no problem with grouping as such. I am in support of the grouping concept. I see the benefit of group based handling for the midcom agents.= For this reason, I believe, the group IDs are to be assigned by the agents, a= nd not the middlebox. Further, I dont see how this is related to PRR reservation= s. >=20 > Cheers, >=20 > Juergen > --=20 > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-= 15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-= 55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec= .de >=20 regards, suresh =3D=3D=3D=3D=3D _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Sep 15 13:12:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12630 for ; Mon, 15 Sep 2003 13:12:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ywtO-0000EB-Tk for midcom-archive@odin.ietf.org; Mon, 15 Sep 2003 13:12:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FHC2la000849 for midcom-archive@odin.ietf.org; Mon, 15 Sep 2003 13:12:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ywtN-0000DA-Jx; Mon, 15 Sep 2003 13:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ywtF-0000Cn-5U for midcom@optimus.ietf.org; Mon, 15 Sep 2003 13:11:53 -0400 Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12591 for ; Mon, 15 Sep 2003 13:11:43 -0400 (EDT) Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 15 Sep 2003 10:08:19 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8FH8CXq029043; Mon, 15 Sep 2003 10:08:13 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-43.cisco.com [10.32.241.43]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AMD06977; Mon, 15 Sep 2003 10:08:11 -0700 (PDT) Date: Mon, 15 Sep 2003 13:08:09 -0400 Subject: Re: [midcom] Reminder: wg last call Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: midcom@ietf.org To: Pyda Srisuresh From: Melinda Shore In-Reply-To: <20030915163239.92743.qmail@web40411.mail.yahoo.com> Message-Id: <2E70C509-E79F-11D7-85E2-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Monday, September 15, 2003, at 12:32 PM, Pyda Srisuresh wrote: >>> >>> A. NAT is configured on a per-interface basis. As such, the >>> Midcom/NAT transactions would be specified on a >>> per-interface >> basis. >> >> I do not share this view. A midcom agent has the intention and >> capability >> to specify endpoints of communication across the middlebox. Which >> interfaces >> of the middlebox are affected is not subject of midcom transactions. > > It would be when the middlebox has several interfaces. The question is fraught with all sorts of problems. For example, it's probably not reasonable to expect agents to know not only which interfaces a middlebox has but also how they're routed, at least in an even modestly complex environment. Nevertheless I do think that this is one area where there are more benefits from allowing the possibility of doing this than from not allowing it. Frankly my expectation in the general case would be for an agent to send a request without specifying the interface and allow the middlebox to choose one, either returning (or not) the selected interface. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Sep 15 19:53:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02805 for ; Mon, 15 Sep 2003 19:53:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z39V-0003mV-Ng for midcom-archive@odin.ietf.org; Mon, 15 Sep 2003 19:53:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FNr5OS014529 for midcom-archive@odin.ietf.org; Mon, 15 Sep 2003 19:53:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z39R-0003lV-CX; Mon, 15 Sep 2003 19:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z38m-0003kQ-2R for midcom@optimus.ietf.org; Mon, 15 Sep 2003 19:52:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02755 for ; Mon, 15 Sep 2003 19:52:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z38k-0000NP-00 for midcom@ietf.org; Mon, 15 Sep 2003 19:52:18 -0400 Received: from web40407.mail.yahoo.com ([66.218.78.104]) by ietf-mx with smtp (Exim 4.12) id 19z38j-0000Mq-00 for midcom@ietf.org; Mon, 15 Sep 2003 19:52:17 -0400 Message-ID: <20030915235147.51442.qmail@web40407.mail.yahoo.com> Received: from [66.224.113.194] by web40407.mail.yahoo.com via HTTP; Mon, 15 Sep 2003 16:51:47 PDT Date: Mon, 15 Sep 2003 16:51:47 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Reminder: wg last call To: Melinda Shore Cc: midcom@ietf.org In-Reply-To: <2E70C509-E79F-11D7-85E2-000A95E35274@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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --- Melinda Shore wrote: > On Monday, September 15, 2003, at 12:32 PM, Pyda Srisuresh wrote: > >>> > >>> A. NAT is configured on a per-interface basis. As such, the > >>> Midcom/NAT transactions would be specified on a > >>> per-interface > >> basis. > >> > >> I do not share this view. A midcom agent has the intention and > >> capability > >> to specify endpoints of communication across the middlebox. Which > >> interfaces > >> of the middlebox are affected is not subject of midcom transactions. > > > > It would be when the middlebox has several interfaces. > > The question is fraught with all sorts of problems. For example, it's > probably not reasonable to expect agents to know not only which > interfaces > a middlebox has but also how they're routed, at least in an even > modestly > complex environment. Nevertheless I do think that this is one area > where > there are more benefits from allowing the possibility of doing this than > from not allowing it. Frankly my expectation in the general case would > be > for an agent to send a request without specifying the interface and > allow > the middlebox to choose one, either returning (or not) the selected > interface. In the case where a middlebox is configured with NAT/Firewall on a single interface, I guess, the transactions could default to that specific interface when the interface is not specified. > > Melinda > regards, suresh ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Sep 15 20:58:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05060 for ; Mon, 15 Sep 2003 20:58:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z4AN-0006Z3-3q for midcom-archive@odin.ietf.org; Mon, 15 Sep 2003 20:58:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8G0w3qQ025230 for midcom-archive@odin.ietf.org; Mon, 15 Sep 2003 20:58:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z4AL-0006YW-9G; Mon, 15 Sep 2003 20:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z49j-0006YG-E8 for midcom@optimus.ietf.org; Mon, 15 Sep 2003 20:57:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05038 for ; Mon, 15 Sep 2003 20:57:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z49g-00019h-00 for midcom@ietf.org; Mon, 15 Sep 2003 20:57:20 -0400 Received: from web13107.mail.yahoo.com ([216.136.174.152]) by ietf-mx with smtp (Exim 4.12) id 19z49g-00019e-00 for midcom@ietf.org; Mon, 15 Sep 2003 20:57:20 -0400 Message-ID: <20030916005717.19809.qmail@web13107.mail.yahoo.com> Received: from [200.244.53.133] by web13107.mail.yahoo.com via HTTP; Mon, 15 Sep 2003 17:57:17 PDT Date: Mon, 15 Sep 2003 17:57:17 -0700 (PDT) From: Daniel Fonseca Subject: Re: [midcom] Reminder: wg last call To: Pyda Srisuresh , Melinda Shore Cc: midcom@ietf.org In-Reply-To: <20030915235147.51442.qmail@web40407.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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --- Pyda Srisuresh wrote: > > --- Melinda Shore wrote: > > On Monday, September 15, 2003, at 12:32 PM, Pyda > Srisuresh wrote: > > >>> > > >>> A. NAT is configured on a per-interface > basis. As such, the > > >>> Midcom/NAT transactions would be > specified on a > > >>> per-interface > > >> basis. > > >> > > >> I do not share this view. A midcom agent has > the intention and > > >> capability > > >> to specify endpoints of communication across > the middlebox. Which > > >> interfaces > > >> of the middlebox are affected is not subject of > midcom transactions. > > > > > > It would be when the middlebox has several > interfaces. > > > > The question is fraught with all sorts of > problems. For example, it's > > probably not reasonable to expect agents to know > not only which > > interfaces > > a middlebox has but also how they're routed, at > least in an even > > modestly > > complex environment. Nevertheless I do think that > this is one area > > where > > there are more benefits from allowing the > possibility of doing this than > > from not allowing it. Frankly my expectation in > the general case would > > be > > for an agent to send a request without specifying > the interface and > > allow > > the middlebox to choose one, either returning (or > not) the selected > > interface. > > In the case where a middlebox is configured with > NAT/Firewall on a single > interface, I guess, the transactions could default > to that specific interface > when the interface is not specified. > > > > > Melinda > > > > regards, > suresh > > ===== (I found the following explanation very hard to write clearly about. Let me know if it's still confusing.) suresh, I was thinking about the case you mentioned previously, regarding specifically the interfaces connected to networks with overlapping addresses or different IP versions (did I get it right?). However, I think the protocol is meant to be transparent to the end applications. Under those circumstances, I was not able to come up with any realistic scenario where an app would attempt to connect to an address of a different version, or even know about a host in some other network with the same address space. The former seems unlikely to me, and the latter would only be possible if a Twice-NAT was already defined at the middlebox. But then the middlebox would already "know" which interfaces are involved in the transaction. That is also the case with different IP versions. Will the ALG be responsible for keeping its own NAT table, with all addresses and interfaces? Hope that was clear enough, Daniel __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Sep 15 23:11:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08314 for ; Mon, 15 Sep 2003 23:11:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z6FA-0002q1-4H for midcom-archive@odin.ietf.org; Mon, 15 Sep 2003 23:11:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8G3B7Eb010900 for midcom-archive@odin.ietf.org; Mon, 15 Sep 2003 23:11:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z6F5-0002pB-Sb; Mon, 15 Sep 2003 23:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z6ET-0002oQ-3A for midcom@optimus.ietf.org; Mon, 15 Sep 2003 23:10:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08283 for ; Mon, 15 Sep 2003 23:10:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z6EO-0002Jq-00 for midcom@ietf.org; Mon, 15 Sep 2003 23:10:20 -0400 Received: from web40407.mail.yahoo.com ([66.218.78.104]) by ietf-mx with smtp (Exim 4.12) id 19z6EO-0002JN-00 for midcom@ietf.org; Mon, 15 Sep 2003 23:10:20 -0400 Message-ID: <20030916030950.84862.qmail@web40407.mail.yahoo.com> Received: from [66.224.113.194] by web40407.mail.yahoo.com via HTTP; Mon, 15 Sep 2003 20:09:50 PDT Date: Mon, 15 Sep 2003 20:09:50 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Reminder: wg last call To: Daniel Fonseca , Melinda Shore Cc: midcom@ietf.org In-Reply-To: <20030916005717.19809.qmail@web13107.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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --- Daniel Fonseca wrote: > --- Pyda Srisuresh wrote: > > > > --- Melinda Shore wrote: > > > On Monday, September 15, 2003, at 12:32 PM, Pyda > > Srisuresh wrote: > > > >>> > > > >>> A. NAT is configured on a per-interface > > basis. As such, the > > > >>> Midcom/NAT transactions would be > > specified on a > > > >>> per-interface > > > >> basis. > > > >> > > > >> I do not share this view. A midcom agent has > > the intention and > > > >> capability > > > >> to specify endpoints of communication across > > the middlebox. Which > > > >> interfaces > > > >> of the middlebox are affected is not subject of > > midcom transactions. > > > > > > > > It would be when the middlebox has several > > interfaces. > > > > > > The question is fraught with all sorts of > > problems. For example, it's > > > probably not reasonable to expect agents to know > > not only which > > > interfaces > > > a middlebox has but also how they're routed, at > > least in an even > > > modestly > > > complex environment. Nevertheless I do think that > > this is one area > > > where > > > there are more benefits from allowing the > > possibility of doing this than > > > from not allowing it. Frankly my expectation in > > the general case would > > > be > > > for an agent to send a request without specifying > > the interface and > > > allow > > > the middlebox to choose one, either returning (or > > not) the selected > > > interface. > > > > In the case where a middlebox is configured with > > NAT/Firewall on a single > > interface, I guess, the transactions could default > > to that specific interface > > when the interface is not specified. > > > > > > > > Melinda > > > > > > > regards, > > suresh > > > > ===== > > (I found the following explanation very hard to write > clearly about. Let me know if it's still confusing.) > > suresh, I was thinking about the case you mentioned > previously, regarding specifically the interfaces > connected to networks with overlapping addresses or > different IP versions (did I get it right?). However, > I think the protocol is meant to be transparent to the > end applications. If you are referign to the Midcom protocol, it is meant to manage middlebox resources so the middlebox will not need ALG support. > > Under those circumstances, I was not able to come up > with any realistic scenario where an app would attempt > to connect to an address of a different version, or I was refering to a IPv4 or IPv6 public network. > even know about a host in some other network with the > same address space. The former seems unlikely to me, > and the latter would only be possible if a Twice-NAT > was already defined at the middlebox. But then the > middlebox would already "know" which interfaces are > involved in the transaction. That is also the case > with different IP versions. > Why is that? There are NATs and forewalls that permit traffic between IPv4 and IPv6 realms. > Will the ALG be responsible for keeping its own NAT > table, with all addresses and interfaces? Are you refering to a midcom agent? The midcom agent might do so. The middlebox will also do that independent of the midcom agent. > > > Hope that was clear enough, Daniel - there are several scenarios where a middlebox might have multiple initerface specific middlebox configurations on the same box. > Daniel > cheers, suresh ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Sep 16 06:20:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01368 for ; Tue, 16 Sep 2003 06:20:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zCwN-0008OB-Kn for midcom-archive@odin.ietf.org; Tue, 16 Sep 2003 06:20:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GAKAwH032221 for midcom-archive@odin.ietf.org; Tue, 16 Sep 2003 06:20:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zCwG-0008NA-4t; Tue, 16 Sep 2003 06:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zCw8-0008MU-2X for midcom@optimus.ietf.org; Tue, 16 Sep 2003 06:19:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01362 for ; Tue, 16 Sep 2003 06:19:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zCw4-0006Om-00 for midcom@ietf.org; Tue, 16 Sep 2003 06:19:52 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19zCw3-0006OY-00 for midcom@ietf.org; Tue, 16 Sep 2003 06:19:51 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.9) with ESMTP id h8GAJMgu017269; Tue, 16 Sep 2003 12:19:22 +0200 (CEST) Received: from [10.1.1.171] (m-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id EC7B4C8C7C; Tue, 16 Sep 2003 11:50:39 +0200 (CEST) Date: Tue, 16 Sep 2003 12:19:52 +0200 From: =?ISO-8859-1?Q?J=FCrgen_Quittek?= To: Pyda Srisuresh , Daniel Fonseca , midcom@ietf.org Subject: Re: was: Re: [midcom] Reminder: wg last call Message-ID: <2147483647.1063714792@[10.1.1.171]> In-Reply-To: <20030915150658.43842.qmail@web40407.mail.yahoo.com> References: <20030915150658.43842.qmail@web40407.mail.yahoo.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Pyda, --On 15.09.2003 8:06 Uhr -0700 Pyda Srisuresh wrote: > > --- J=B8rgen_Quittek wrote: >> Daniel, >> >> Thank you very much for all your comments. >> >> Most of them are very helpful and we will apply them. >> Please see detailed replies inline. >> > <... stuff deleted> > >> >> > Page 10, "- internal IP address wildcard support >> > - external IP address wildcard support" >> > (I believe this has been mentioned recently in the >> > list) >> > It is very common for middlebox-ish devices to have >> > more than two interfaces. How is midcom going to >> > handle that? Shouldn't there be an interface-id? This >> > involves many other sections in the text. >> >> In the MIDCOM information model there is just an internal >> (protected, private, ...) network and and external (public?) >> network. How many interfaces of a middlebox are connected to >> which of these two networks is not of interest to applications >> requesting the box to just ENABLE communication between two >> specified end points. Which interfaces are involved in serving >> such a request needs to be identified by the middlebox internally. >> > > Juergen - If you have several interfaces on the private realm and a interface > on the public relam, you might choose to have NAT/FW configured on just the > public interface. No problem with that. It is OK to use an information model a > describe a theory of operation. But, the model cannot be imposed as is on the > middleboxes. I do not see any reason why not. The information contained in the model is sufficient to clearly specify the required configuration. > A middlebox may be attached to several overlapping private > networks. A middlebox may also have several public interfaces (combination of > V4 and v6). For these reasons, a middlebox must be configurable on a > per-interface basis. I would agree completely if we were talking about a middlebox management MIB module. But we are not. The goal of the MIDCOM protocol is not managing middleboxes. The goal is allowing agents to request the middlebox to enable communication between specified end points. What is the correct middlebox configuration that enables the specified stream of packets has to be determined by the middlebox, not by the agent! Imagine a combined box integrating firewall and NAT. It would be a tough job for the agent to find out - which interfaces are passed by the specified packets - which interfaces are served by the firewall - how firewall and NAT interact (maybe the FW is passed twice, once before and once after address translation. Then you need to configure two firewall rules per direction) Also it is a tough job configuring a firewall correctly in case of overlapping rules. Prioritization (or just ordering) of rules is very important. All this is not a job of - say - a SIP server or a video conferencing server that wants to request middleboxes to enable communication across it. Still the information sent from such a server to a middlebox as defined in the current version of the semantics document should be completely sufficient for the middlebox to determine which interfaces to use, which firewall rule priority is required, and how many firewall entries are necessary for correctly configuring an integrated NAT/FW. Thus I think the current model is sufficient and can be applied by the middlebox correctly. The complexity of transforming the requests to low level middlebox configuration is a burden of the middlebox. But this is fine. If the middlebox is a very small and simple device, also the transformation is very simple. If the middlebox is complex, then also the complexity of the transformation is higher. This scaleable approach is much better than requesting every MIDCOM agent to be able to manage any kind of complex middleboxes. Cheers, Juergen --=20 Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de > <.. stuff deleted> > > > =3D=3D=3D=3D=3D > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Sep 16 07:12:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03415 for ; Tue, 16 Sep 2003 07:12:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zDkZ-0001Ti-16 for midcom-archive@odin.ietf.org; Tue, 16 Sep 2003 07:12:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GBC2go005676 for midcom-archive@odin.ietf.org; Tue, 16 Sep 2003 07:12:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zDkW-0001T5-Qz; Tue, 16 Sep 2003 07:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zDk4-0001RX-1p for midcom@optimus.ietf.org; Tue, 16 Sep 2003 07:11:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03327 for ; Tue, 16 Sep 2003 07:11:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zDjz-0006yw-00 for midcom@ietf.org; Tue, 16 Sep 2003 07:11:27 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19zDjy-0006xz-00 for midcom@ietf.org; Tue, 16 Sep 2003 07:11:26 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.9) with ESMTP id h8GBAugu019791; Tue, 16 Sep 2003 13:10:56 +0200 (CEST) Received: from [10.1.1.171] (m-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 88168C8B99; Tue, 16 Sep 2003 12:42:13 +0200 (CEST) Date: Tue, 16 Sep 2003 13:11:26 +0200 From: =?ISO-8859-1?Q?J=FCrgen_Quittek?= To: Pyda Srisuresh , midcom@ietf.org Cc: stiemerling@ccrle.nec.de, taylor@nortelnetworks.com Subject: Re: [midcom] Reminder: wg last call Message-ID: <2147483647.1063717886@[10.1.1.171]> In-Reply-To: <20030915163239.92743.qmail@web40411.mail.yahoo.com> References: <20030915163239.92743.qmail@web40411.mail.yahoo.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Pyda, --On 15.09.2003 9:32 Uhr -0700 Pyda Srisuresh wrote: > Jurgen, > > Please see my comments below. > > regards, > suresh > > --- J=B8rgen_Quittek wrote: >> Pyda, >> >> Thanks for your comments. Please see replies to some of them inline. >> >> --On 06.09.2003 14:15 Uhr -0700 Pyda Srisuresh wrote: >> >> > Below is text of the e-mail (a little revised) I sent to the authors >> earlier. I >> > am including the text for wider audience. Below are my outstanding comments >> on >> > the draft. >> > >> > 1. For a NAT middlebox, I believe, the semantics ought to cover the >> following >> > transactions. My comments assume the following. >> > >> > A. NAT is configured on a per-interface basis. As such, the >> > Midcom/NAT transactions would be specified on a per-interface >> basis. >> >> I do not share this view. A midcom agent has the intention and capability >> to specify endpoints of communication across the middlebox. Which interfaces >> of the middlebox are affected is not subject of midcom transactions. > > It would be when the middlebox has several interfaces. Then the MIDCOM server needs to identify the proper interfaces or configure all of them. The primary goal is enabling communication between the specified end points. >> >> The MIDCOM information model simplifies the network view by just separating >> an internal network and an external network. Whether or not the middlebox has >> one or more interfaces connected to any of them is considered an internal >> matter >> of the middlebox. > > The above argument would suffice for an information model where the network > view is merely in terms of an internal network and an external network. This > would not be adequate on an operating middlebox. Both NAT and firewall oftne You are right. It is not adequate within the middlebox. The MIDCOM server needs to translate the higher-level information into the level required at the middlebox. This internally required level heavily depends on the actual implementation of the middlebox and should not be reflected by the MIDCOM protocol. > have interface specific configurations. midcom agent will have all the > information it needs from the middlebox using per-intarface configurations. We should not require all MIDCOM agents to interpret low-level configuration information of any kind of firewall and NAT. Please see the comment on this in my previous message. >> >> There is no statement in framework or requirements that oblige an agent to >> find >> out which interfaces a middlebox is using. >> > > The above two documents are agnostic to the deployment scenarios and do not > assume a specific type of middlebox or network configurations. Yes. That's a feature, not a shortcoming. The MIDCOM protocol semantics also does not assume a specific type of middlebox or network configurations. Consequently, the semantics are defined in a way, that firewalls and NATs share as much as possible. >> > B. End-point below is to be refered as >> > for a PortBind. End-point for an address Bind will be >> > . The IP address can be V4 or V6. >> > C. The transactions specified below can be applicable to one or more >> > end-points. This will include address ranges, address >> > wild-carding, port ranges, and port wild-carding. >> > >> > >> > SetMapOwner [Full | Partial] [] >> > - SetMapowner may be used by an agent to claim >> > ownership on a complete NAT map entry or a >> > portion of the entry. AgentId will be set as the >> > owner of the entire map entry or portion thereof. >> > >> > (CreateBind | CreatePortBind) >> > >> > - Agent specifies all the requisite Parameters for >> > Bind(s) or PortBind(s). Agent requests middlebox >> > to create a BIND and respond back with an assigned >> > BindId. Middlebox to validate the authorization >> > prior to responding. >> > >> > (RequestCreateBind | RequestPortCreateBind) >> > [Oddity option] >> > - Agent requests the Middlebox to create BIND(s) for >> > the given End-point, optionally with an Oddity >> > requirement. Middlebox to validate the >> > authorization, prior to assgining a BIND and >> > a BindId and returning the response. >> > >> > CreateOutboundSession >> > | >> > | >> > >> > >> > - Agent specifies all the requisite Parameters for >> > an outbound session. Agent requests middlebox >> > to create a session as specified and respond back >> > with an assigned BindId. >> > The session may have one or two end-point >> > translations. The session may be derived directly >> > from the address map (or) from associated Bind-IDs. >> > Middlebox to validate the authorization prior to >> > responding. Note, the session tuple may have >> > wild-card elements. >> > >> > RequestCreateOutboundSession >> > | >> > | >> > >> > - Agent requests the Middlebox to create an outbound >> > session for the given session tuple, using one or >> > more map entries and/or end-point BINDs. Agent >> > to validate he authorization prior to responding >> > back with a new session and session-id. As before, >> > the session tuple may have wild-card elements. >> > >> > CreateInboundSession, >> > RequestCreateInboundSession >> > - Similar to the outbound counterparts. >> > >> > ModifyBindParameters >> > [] [MaximumIdletime>] [] >> > - These parameters may be specified either at Bind >> > creation time or later. >> > >> > ModifySessionParameters >> > [] [MaximumIdletime>] [] >> > - These parameters may be specified either at session >> > creation time or later. Note, session here refers >> > to the NAT data sessions, not the Midcom agent >> > session. >> > >> > In particular, I would like to mention the notion of three resources >> > a NAT middlebox and midcom agent need to be cognizant of - >> > Address map entries, Binds and sessions. These resources may be a) created >> by >> > the agent, b) created by the NAT middlebox, or c) paramaters modified by >> the >> > agent. >> >> The way I see it, MIDCOM does not distinguish binding and session (as the NAT >> MIB does). > > Why is that? Binds and sessions must be distinguished. This is nothign new. You > might want to refer RFC 3489 as to why it is important to make this distinction > n the context of NAPT devices. I do not see any contradiction with RFC 3489. I understand that for a NAT it is important to distinguish binding and session (depending of the funtionality and the implementation). However, I do not see why this distinction would be an issue for a MIDCOM agent. Again: the agent requests ENABLING communication between specified end points. The realization in terms of bindings and sessions is left to the middlebox. The middlebox can consider all its functionality and implementation properties when enabling the communication. >> The point is that the MIDCOM protocol is not a middlebox management protocol, >> but a >> protocol that allows applications to express requests for enabling >> communication >> across a middlebox. > > Agreed. But, you cannot mandate that a middlebox to support requests that it is > not capable of. Ex: If an agent creates a port-Bind-ID and expects this Bind-Id If a NAT is not capable, it just should reject the request. > to be used for all outgoign sessions by the NAPT device, the agent is going to > be disappointed on certain boxes. What do you mean with all outgoing sessions? The operational model defined in RFC 3303 and used for the examples in the semantics draft rather suggest to have a MIDCOM request per session (to be precisely: here 'session' relates to application level session, not necessarily to NAT sessions). I wonder why a middlebox would not be capable of providing such fine-grained bindings. >> >> > 2. The notion of PRR is incomplete without the context of the entire >> address >> > map entry. The reservation may not be specific to address/address-port >> alone. >> > My view of this is simply that PRR is just another notion of ownership >> claim. >> > it just happens to be in relation to an address map entry. >> >> The intention behind PRR is just to reserve addresses at the middlebox. >> This can be doen without mapping them already. > > Jurgen - A middlebox may have several address map entries configured on an > interface. Which of the entries do you refer the addresses to? Why do you think > the agent shoudl be allowed to reserve addresses alone? It is the middlebox' task to find out which address mapping is affected. The concept of address mapping remains hidden for the MIDCOM agent. >> >> > 3. When you combine the notion of PRR wth PER, the state transition diagram >> in >> > section 2.3.13 woudl be simplified, with the proviso that there would be >> three >> > types of policy rules (address map entries, binds and sessions). >> >> Again, binds and sessions cannot be distinguished in the midcom world. > > Again, this is not true. Can you point me to any reference that said this? This is in line with RFC 3303 and 3304, although not explicitly mentioned there. Can you point to any reference that contradicts this? >> >> > 4. I agree with your notion of Session establishment and session >> termination >> > transactions. >> > >> > 5. I believe, the group Ids an agent would use during the lifetime of a >> Midcom >> > session should be specified by the agent - either at the midcom session >> > establishment time or afterwards whild the midcom session is alive. Given >> that >> > group-Ids are specific to an agent, it shoudl be agent's responsibility to >> > assign group IDs, not that of the middlebox's. Further, given that there >> are 3 >> >> Group IDs need to be unique per middlebox. > > Why is that? Groups are a convenience concept introduced for the benefit of > agents and hence are relevant to midcom agents. Agents use Group Ids to process > a group of resources in a unique way. As such, the midcom agents ought to be > able to select groupIds unique to itself. I donot see a reason why the > uniqueness of the following tuple not be adequate? (AgentId, > MiddleboxFunctionResourceType, GroupId). > >> This is hard to achieve if the agent assigns them. > > On the contrary, I believe the opposite. Please see my note above. I see, agreed. But still I wonder why you say "group-Ids are specific to an agent, it shoudl be agent's responsibility to assign group IDs"? Why are group IDs specific to an agent? They are used to address a group of rules on a certain middlebox. So the primary requirement is having them unique per middlebox. >> >> > different types of resources (map entries, Binds and sessions), there >> shoudl be >> > three different sets of group-Ids, one set for each resource type. >> > Middlebox will assign a default groupId of 0 to all entities that are not >> > assigned a groupId by the agent. >> >> I prefer to have reservation rules and enable rules (bindings) to be >> able to share a group. > > Why do you need reservation rules to be able to share a group? I find the > reservation concept alien to NAT middleboxes. Are you talking about transfer of > ownership from an address map entry to BINDs? if so, I dont see that as > problem. If not, I donot know what you are talking about. Several of our controversies are based on our different view points. You look a the issues from a NAT perspective, I am looking from a MIDCOM agent perspective. >From an agent perspective I would like to have rules belonging to the same (application-level) session into one group. Then I can easily extend the lifetime of all rules, when I want to extend the lifetime of the entire session. Or I can terminate everything at once without forgetting a rule. But when setting up a session, I can set up some reservation rules immediately, for some I have to make a reservation first and wait for more signaling messages until session setup is complete. During that time, I assign all rules to the same group. When session setup is complete, all rules are reserve rules. This is different during initial setup or when the session is modified while being active. Then also reserve rules are members. If session setup fails, I can just delete the group with all rules including reservation rules. Of course, from a NAT point of view, this is different. There are essential differences between reservations and bindings/sessions. However, this difference should be kept internal. The MIDCOM server can easily maintain groups consisting of address reservations, NAT bindings/sessions, and firewall rules. I do not think NAT bindings and address bindings are much more alien to each other than NAT bindings and firewall rules are. Cheers, Juergen >> because then the agent can extend or delete >> sets of them belonging together by just accessing a single group. > > I have no problem with grouping as such. I am in support of the grouping > concept. I see the benefit of group based handling for the midcom agents. For > this reason, I believe, the group IDs are to be assigned by the agents, and not > the middlebox. Further, I dont see how this is related to PRR reservations. > >> >> Cheers, >> >> Juergen >> -- >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de >> > regards, > suresh > > =3D=3D=3D=3D=3D > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Sep 16 14:41:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01197 for ; Tue, 16 Sep 2003 14:41:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zKlB-0003O2-Av for midcom-archive@odin.ietf.org; Tue, 16 Sep 2003 14:41:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GIf95c013014 for midcom-archive@odin.ietf.org; Tue, 16 Sep 2003 14:41:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zKl4-0003NQ-8p; Tue, 16 Sep 2003 14:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zKkJ-0003MV-Do for midcom@optimus.ietf.org; Tue, 16 Sep 2003 14:40:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01163 for ; Tue, 16 Sep 2003 14:40:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zKkG-0007QN-00 for midcom@ietf.org; Tue, 16 Sep 2003 14:40:12 -0400 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 19zKkF-0007QF-00 for midcom@ietf.org; Tue, 16 Sep 2003 14:40:11 -0400 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 0571655D82; Tue, 16 Sep 2003 20:39:41 +0200 (CEST) Received: from james (unknown [212.201.47.15]) by merkur.iu-bremen.de (Postfix) with ESMTP id 5825A55D68; Tue, 16 Sep 2003 20:39:40 +0200 (CEST) Received: by james (Postfix, from userid 1000) id D8CF08516; Tue, 16 Sep 2003 20:39:39 +0200 (CEST) Date: Tue, 16 Sep 2003 20:39:39 +0200 From: Juergen Schoenwaelder To: Pyda Srisuresh Cc: "Wijnen, Bert (Bert)" , rrohit74@hotmail.com, npai@cisco.com, raraghun@cisco.com, cliffwang2000@yahoo.com, midcom@ietf.org Subject: Re: [midcom] RE: NAT-MIB review Message-ID: <20030916183939.GA820@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Pyda Srisuresh , "Wijnen, Bert (Bert)" , rrohit74@hotmail.com, npai@cisco.com, raraghun@cisco.com, cliffwang2000@yahoo.com, midcom@ietf.org References: <7D5D48D2CAA3D84C813F5B154F43B15502331524@nl0006exch001u.nl.lucent.com> <20030915030106.33274.qmail@web40407.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030915030106.33274.qmail@web40407.mail.yahoo.com> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Sun, Sep 14, 2003 at 08:01:06PM -0700, Pyda Srisuresh wrote: > A bunch of your questions relate to MIDCOM compliance. Unfortunately, the > MidcomBase MIB is not published yet. Until the Midcombase MIB is out, the > MIDCOM extension done in the NAT MIB would not make much sense to the readers, > I am afraid. DO let me know if you have any suggestions on how to go about > this. Thanks. You simply can't publish extensions to something that does not exist. So either wait with the publication of the NAT-MIB until the MIDCOM MIB is also ready to go or remove all the MIDCOM specific things and add them later via AUGMENTS or a NAT-MIB revision or whatever is the right thing that needs to be done. The point is that I can't judge whether the MIDCOM specific things make sense to me without having the MIDCOM MIB in my hands. And the same will hold true for implementors. > > > 7) Section 4.3 says that binds which point to non-existing address > > > maps are not allowed. In the MIB definitions, it would be very > > > useful to say precisely what happens if one tries to violate the > > > rule (that is, which error code is actually generated when I try > > > to delete an address map with pending binds or try to create a > > > bind which points to a non-existing address map). > OK. When you try to delete an address map with pending binds, all associated > BINDs are removed. No error is created. Typically, address maps are not edited > once confgured.When you try to create a BIND pointing to a non-existing address > map (or) an exisitng address map, but has no relevance to the BIND, BIND > creation fails - error code: UnknownAddressMapEntry (or) > InvalidAddressMapEntry. Where does this error code go to??? I thought that you would get an SNMP error code for the set request...` > > > 11) What does an idle timeout of 0 seconds actually mean? (This > > > question affects natConfUdpDefIdleTimeout, > > > natConfIcmpDefIdleTimeout, natConfOtherDefIdleTimeout, > > > natConfTcpDefIdleTimeout and natConfTcpDefNegTimeout. > > When idle timeout is set to zero, these fields will be assigned their > respective DEFVAL values. This needs to be spelled out in the DESCRIPTION clauses. > > > 17) What are the semantics of zero-length natConfAddrMapConfigName > > > values? > > A name with zero-length is invalid and has no impact. So why is it allowed if it is invalid? Or do you mean a zero-length string is a special name which identifies no address map? > > > Can I actually have multiple natConfAddrMapConfigName > > > objects with the same value? > No. NatConfAddrMapTable indexed by natConfAddrMapName. The natConfAddrMapTable is indexed by natConfAddrMapName but I was talking about natConfAddrMapConfigName which is a column of the natConfInterfaceTable. (Perhaps the naming scheme is a bit confusing. ;-) > > > If not, what happens if I try to > > > create them? And why do you identify address maps by name when all > > > the other entities are identified by numbers? > > Address map is essentially a file name with one or more address map entries > within it. An interface is associated with a unique address map at the > configuration time. Well, sounds like one particular implementation approach... > As for the other entries identified by numbers - are you referign to Bind-Id, > session-Id etc? These are NAt generated, so it makes sense for them to be a > number. OK - it is the WGs decision after all. But still, you want to clarify what happens if I assign the same value to different instances of natConfAddrMapConfigName. > > > 20) What precisely happens if I write a value != 0 to > > > natConfLocalPortFrom, natConfLocalPortTo, natConfGlobalPortFrom, > > > natConfGlobalPortTo on a basic NAT? > > That would not be considered a BasicNat address map. As a result, this woudl > not generate address BINDs. If the parameters donot fit the requirements of a > static map or NAPT or one of the other supported maps, the address map entry > will be declared invalid and will not be used. Please spell that out in the DESCRIPTION clauses. > > > 23) Please say precisely which error is to be generated if you set > > > natAddrBindAddrMapName or natAddrPortBindAddrMapName to a non > > > existent addrMapName. > > For the NAT devices that are not MIDCOM compliant or donot communicate with > MIDCOm agents, this is not an issue as the MAP name is generated by the NAT > devices alone. > > In the case a NAT device is in session with a MIDCOM agent, INVALID_MAP_NAME > error will be issued when the specified MapName is invalid. Again, I would expect an SNMP error code... > > > 26) The natAddrBindTable, natAddrPortBindTable and natSessionTable > > > have no StorageType, see the MIB review guidelines document. > > > > > > (In general, one can also ask why these tables are not part of the > > > configuration branch since I can do row creation here. Also there > > > are counters in the translation tables which are actually > > > statistics. Personally, I would just drop the branches since they > > > serve no real value and only increase the length of the OIDs.) > > natAddrBindTable, natAddrPortBindTable and natSessionTable are genrated > dynamically by the NAt device and are not saved between reboots. Unlike these, > natConfig is a configuration object. So why do I then have a RowStatus column? > Perhaps, Rohit will respond to this in detail. OK, I will see what Rohit has to say about this. > > > 27) What is the "query id" you refer to in the description of > > > natAddrPortBindLocalPort and natAddrPortBindGlobalPort? If you > > > mean the ICMP type code, then please say ICMP type code. > > This is refering to the Identifier field in the header. OK. Then please say clearly in the DESCRIPTION that this refers to the Identifier field of ICMP messages. > > > 39) In the security considerations, you simply state that "some of > > > these objects could contain sensitive information, e.g. bind > > > information". For someone deploying this, it might be useful to > > > have a more explicit discussion of the security implications. > > Perhaps, this will make more sense when the Midcom MIB is reviewed and > published. The objective of the Midcom MIB is to ensure that only the > authorized agents are allowed to modify the NAT resources; And, SNMPv3 > ishall be the management protocol. Not sure I understand this. The NAT-MIB is just a MIB like all others so the access decision is done by VACM like for all other MIBs. Hence, I believe the NAT-MIB should discuss which objects are specifically sensitive and for what reason. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Sep 16 14:55:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01949 for ; Tue, 16 Sep 2003 14:55:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zKyd-0003q7-O0 for midcom-archive@odin.ietf.org; Tue, 16 Sep 2003 14:55:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GIt3Xf014738 for midcom-archive@odin.ietf.org; Tue, 16 Sep 2003 14:55:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zKyc-0003pb-Sd; Tue, 16 Sep 2003 14:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zKyL-0003pH-3g for midcom@optimus.ietf.org; Tue, 16 Sep 2003 14:54:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01918 for ; Tue, 16 Sep 2003 14:54:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zKyI-0007dZ-00 for midcom@ietf.org; Tue, 16 Sep 2003 14:54:42 -0400 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 19zKyH-0007dJ-00 for midcom@ietf.org; Tue, 16 Sep 2003 14:54:41 -0400 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 74B9E55D83; Tue, 16 Sep 2003 20:54:11 +0200 (CEST) Received: from james (unknown [212.201.47.15]) by merkur.iu-bremen.de (Postfix) with ESMTP id C7A8A55D68; Tue, 16 Sep 2003 20:54:10 +0200 (CEST) Received: by james (Postfix, from userid 1000) id 51B788516; Tue, 16 Sep 2003 20:54:10 +0200 (CEST) Date: Tue, 16 Sep 2003 20:54:10 +0200 From: Juergen Schoenwaelder To: Rohit.Mehendiratta@utstar.com Cc: bwijnen@lucent.com, npai@cisco.com, raraghun@cisco.com, srisuresh@yahoo.com, cliffwang2000@yahoo.com, midcom@ietf.org, rrohit74@hotmail.com Subject: Re: [midcom] Re: Fwd: RE: NAT-MIB review Message-ID: <20030916185410.GB820@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Rohit.Mehendiratta@utstar.com, bwijnen@lucent.com, npai@cisco.com, raraghun@cisco.com, srisuresh@yahoo.com, cliffwang2000@yahoo.com, midcom@ietf.org, rrohit74@hotmail.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Mon, Sep 15, 2003 at 01:02:56AM -0500, Rohit.Mehendiratta@utstar.com wrote: > 1. As Suresh also mentioned that Midcom MIB is not published yet; thats > why MIDCOM Compliance/Owner Id/Group Id may not make much sense. > What should we do in this case ? As I wrote in another email: Either wait until the MIDCOM MIB is ready to go as well or put these objects in place at a later point in time by using AUGMENTS or whatever is a good choice to handle things. > 2. > > > > > > > 7) Section 4.3 says that binds which point to non-existing address > > > > maps are not allowed. In the MIB definitions, it would be very > > > > useful to say precisely what happens if one tries to violate the > > > > rule (that is, which error code is actually generated when I try > > > > to delete an address map with pending binds or try to create a > > > > bind which points to a non-existing address map). > > In the last revision, i had mentioned snmp error code as > inconsistentErrorValue but there were comments that this error code > is only specific to some snmp version and hence > we shouldn't mention it. I would like to know your opinion on the same. The formal argument would be that inconsistentValue is part of the official SNMP standard and everything else is historic. The more useful response is that there is a well-defined mapping of SNMPv3 error codes to SNMPv1 error codes, see RFC 3584 section 4.4. > 3. I will remove storageType objects on the next version as i don't see > much use of them in this MIB. > Let me know your opinion about the same. The MIB review guidelines say that you should have StorageType columns on tables that have RowStatus columns. Why do you think a storage type is not of much use? Do you assume that all the rows created by a manager are volatile on all implementations? > 4. It is my undretstaning that in most of the customer scenarios, the binds > and sessions are generated dynamically while addrmaps are configured. > Thats why we have separate branches for config and translation. > Even if the bind and session have the rowStatus, i don't anticipate > it to be used widely. I am not sure whether it helps anyone to have different branches for things that are configured and things that are not (or unlikely to be configured). But despite this debatable view of the world, I am wondering why some tables have RowStatus columns which you do not consider to be used for configuration... > 5. Related to notification changes, we will simplify it a lot in the next > version. OK. But it would be good to get the WG involved in the changes and to have the WG agree to the changes. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Sep 16 18:29:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18029 for ; Tue, 16 Sep 2003 18:29:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zOJm-000543-Ir for midcom-archive@odin.ietf.org; Tue, 16 Sep 2003 18:29:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GMT6mQ019467 for midcom-archive@odin.ietf.org; Tue, 16 Sep 2003 18:29:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zOJi-00053X-3w; Tue, 16 Sep 2003 18:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zOJU-00053E-Aq for midcom@optimus.ietf.org; Tue, 16 Sep 2003 18:28:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18005 for ; Tue, 16 Sep 2003 18:28:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zOJR-0004Gm-00 for midcom@ietf.org; Tue, 16 Sep 2003 18:28:45 -0400 Received: from web40407.mail.yahoo.com ([66.218.78.104]) by ietf-mx with smtp (Exim 4.12) id 19zOJQ-0004Fn-00 for midcom@ietf.org; Tue, 16 Sep 2003 18:28:44 -0400 Message-ID: <20030916222813.96045.qmail@web40407.mail.yahoo.com> Received: from [66.224.113.194] by web40407.mail.yahoo.com via HTTP; Tue, 16 Sep 2003 15:28:13 PDT Date: Tue, 16 Sep 2003 15:28:13 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] RE: NAT-MIB review To: j.schoenwaelder@iu-bremen.de Cc: "Wijnen, Bert \(Bert\)" , rrohit74@hotmail.com, npai@cisco.com, raraghun@cisco.com, cliffwang2000@yahoo.com, midcom@ietf.org, Rohit Rohit In-Reply-To: <20030916183939.GA820@iu-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --- Juergen Schoenwaelder wrote: > On Sun, Sep 14, 2003 at 08:01:06PM -0700, Pyda Srisuresh wrote: > > > A bunch of your questions relate to MIDCOM compliance. Unfortunately, the > > MidcomBase MIB is not published yet. Until the Midcombase MIB is out, the > > MIDCOM extension done in the NAT MIB would not make much sense to the > readers, > > I am afraid. DO let me know if you have any suggestions on how to go about > > this. Thanks. > > You simply can't publish extensions to something that does not exist. So > either wait with the publication of the NAT-MIB until the MIDCOM MIB is > also ready to go or remove all the MIDCOM specific things and add them > later via AUGMENTS or a NAT-MIB revision or whatever is the right thing > that needs to be done. The point is that I can't judge whether the > MIDCOM specific things make sense to me without having the MIDCOM MIB > in my hands. And the same will hold true for implementors. > OK. Sounds like, it would be best to remove MIDCOM specific things from the NAT-MIB now. When the MIDCOM MIB is settled, we could issue a separate draft to either augment the original NAT-MIB or issue a new NAT-MIB revision. > > > > 7) Section 4.3 says that binds which point to non-existing address > > > > maps are not allowed. In the MIB definitions, it would be very > > > > useful to say precisely what happens if one tries to violate the > > > > rule (that is, which error code is actually generated when I try > > > > to delete an address map with pending binds or try to create a > > > > bind which points to a non-existing address map). > > OK. When you try to delete an address map with pending binds, all > associated > > BINDs are removed. No error is created. Typically, address maps are not > edited > > once confgured.When you try to create a BIND pointing to a non-existing > address > > map (or) an exisitng address map, but has no relevance to the BIND, BIND > > creation fails - error code: UnknownAddressMapEntry (or) > > InvalidAddressMapEntry. > > Where does this error code go to??? I thought that you would get an SNMP > error code for the set request...` > You are right. I will check with Rohit on the SNMP error code to use. > > > > 11) What does an idle timeout of 0 seconds actually mean? (This > > > > question affects natConfUdpDefIdleTimeout, > > > > natConfIcmpDefIdleTimeout, natConfOtherDefIdleTimeout, > > > > natConfTcpDefIdleTimeout and natConfTcpDefNegTimeout. > > > > When idle timeout is set to zero, these fields will be assigned their > > respective DEFVAL values. > > This needs to be spelled out in the DESCRIPTION clauses. > OK. > > > > 17) What are the semantics of zero-length natConfAddrMapConfigName > > > > values? > > > > A name with zero-length is invalid and has no impact. > > So why is it allowed if it is invalid? Or do you mean a zero-length > string is a special name which identifies no address map? > That sounds good. We will add this to the description. > > > > Can I actually have multiple natConfAddrMapConfigName > > > > objects with the same value? > > No. NatConfAddrMapTable indexed by natConfAddrMapName. > > The natConfAddrMapTable is indexed by natConfAddrMapName but I was > talking about natConfAddrMapConfigName which is a column of the > natConfInterfaceTable. (Perhaps the naming scheme is a bit confusing. > ;-) > These should be different for each interface. > > > > If not, what happens if I try to > > > > create them? And why do you identify address maps by name when all > > > > the other entities are identified by numbers? > > > > Address map is essentially a file name with one or more address map entries > > within it. An interface is associated with a unique address map at the > > configuration time. > > Well, sounds like one particular implementation approach... > Agreed. It could have been numbers. I just spoke with my co-authors of possibly using numbers instead of names. I believe, this is not a big issue either way. We are certainly open to comments from the WG. > > As for the other entries identified by numbers - are you referign to > Bind-Id, > > session-Id etc? These are NAt generated, so it makes sense for them to be a > > number. > > OK - it is the WGs decision after all. But still, you want to clarify > what happens if I assign the same value to different instances of > natConfAddrMapConfigName. > Basically, an address map cannot be reused across different interfaces. Address map entries contain addresses specific to an interface. > > > > 20) What precisely happens if I write a value != 0 to > > > > natConfLocalPortFrom, natConfLocalPortTo, natConfGlobalPortFrom, > > > > natConfGlobalPortTo on a basic NAT? > > > > That would not be considered a BasicNat address map. As a result, this > woudl > > not generate address BINDs. If the parameters donot fit the requirements of > a > > static map or NAPT or one of the other supported maps, the address map > entry > > will be declared invalid and will not be used. > > Please spell that out in the DESCRIPTION clauses. > OK. > > > > 23) Please say precisely which error is to be generated if you set > > > > natAddrBindAddrMapName or natAddrPortBindAddrMapName to a non > > > > existent addrMapName. > > > > For the NAT devices that are not MIDCOM compliant or donot communicate with > > MIDCOm agents, this is not an issue as the MAP name is generated by the NAT > > devices alone. > > > > In the case a NAT device is in session with a MIDCOM agent, > INVALID_MAP_NAME > > error will be issued when the specified MapName is invalid. > > Again, I would expect an SNMP error code... This might be moot when the document is made independent of MIDCOM. > > > > > 26) The natAddrBindTable, natAddrPortBindTable and natSessionTable > > > > have no StorageType, see the MIB review guidelines document. > > > > > > > > (In general, one can also ask why these tables are not part of the > > > > configuration branch since I can do row creation here. Also there > > > > are counters in the translation tables which are actually > > > > statistics. Personally, I would just drop the branches since they > > > > serve no real value and only increase the length of the OIDs.) > > > > natAddrBindTable, natAddrPortBindTable and natSessionTable are genrated > > dynamically by the NAt device and are not saved between reboots. Unlike > these, > > natConfig is a configuration object. > > So why do I then have a RowStatus column? > > > Perhaps, Rohit will respond to this in detail. > > OK, I will see what Rohit has to say about this. > > > > > 27) What is the "query id" you refer to in the description of > > > > natAddrPortBindLocalPort and natAddrPortBindGlobalPort? If you > > > > mean the ICMP type code, then please say ICMP type code. > > > > This is refering to the Identifier field in the header. > > OK. Then please say clearly in the DESCRIPTION that this refers to the > Identifier field of ICMP messages. OK. > > > > > 39) In the security considerations, you simply state that "some of > > > > these objects could contain sensitive information, e.g. bind > > > > information". For someone deploying this, it might be useful to > > > > have a more explicit discussion of the security implications. > > > > Perhaps, this will make more sense when the Midcom MIB is reviewed and > > published. The objective of the Midcom MIB is to ensure that only the > > authorized agents are allowed to modify the NAT resources; And, SNMPv3 > > ishall be the management protocol. > > Not sure I understand this. The NAT-MIB is just a MIB like all others so > the access decision is done by VACM like for all other MIBs. Hence, I > believe the NAT-MIB should discuss which objects are specifically > sensitive and for what reason. NAT configuration must be permitted only by an authorized SNMP application, as incorrect configuration could generate Denial of Service attacks on the network. Monitoring the NAT sessiosn, BINDs and other statitics shoudl not be a cause for security alarm. The fear of unauthorized midcom agents effecting the NAT resources is diminished once the MIB module is devoid of MIDCOM stuff. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany Thanks, Juergen. regards, suresh ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Sep 17 00:25:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28224 for ; Wed, 17 Sep 2003 00:25:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zTsJ-0008RI-B2 for midcom-archive@odin.ietf.org; Wed, 17 Sep 2003 00:25:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8H4P7Zc032436 for midcom-archive@odin.ietf.org; Wed, 17 Sep 2003 00:25:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zTsE-0008QV-Rs; Wed, 17 Sep 2003 00:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zTsA-0008QD-G9 for midcom@optimus.ietf.org; Wed, 17 Sep 2003 00:24:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28203 for ; Wed, 17 Sep 2003 00:24:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zTs8-0000CE-00 for midcom@ietf.org; Wed, 17 Sep 2003 00:24:56 -0400 Received: from web40408.mail.yahoo.com ([66.218.78.105]) by ietf-mx with smtp (Exim 4.12) id 19zTs7-0000C2-00 for midcom@ietf.org; Wed, 17 Sep 2003 00:24:55 -0400 Message-ID: <20030917042425.47563.qmail@web40408.mail.yahoo.com> Received: from [66.224.113.194] by web40408.mail.yahoo.com via HTTP; Tue, 16 Sep 2003 21:24:25 PDT Date: Tue, 16 Sep 2003 21:24:25 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Reminder: wg last call To: "Jürgen_Quittek" , midcom@ietf.org Cc: stiemerling@ccrle.nec.de, taylor@nortelnetworks.com In-Reply-To: <2147483647.1063717886@[10.1.1.171]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id AAA28204 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable --- J=FCrgen_Quittek wrote: > Pyda, >=20 > --On 15.09.2003 9:32 Uhr -0700 Pyda Srisuresh wro= te: >=20 > > Jurgen, > > > > Please see my comments below. > > > > regards, > > suresh > > > > --- J=B8rgen_Quittek wrote: > >> Pyda, > >> > >> Thanks for your comments. Please see replies to some of them inline. > >> > >> --On 06.09.2003 14:15 Uhr -0700 Pyda Srisuresh > wrote: > >> > >> > Below is text of the e-mail (a little revised) I sent to the autho= rs > >> earlier. I > >> > am including the text for wider audience. Below are my outstanding > comments > >> on > >> > the draft. > >> > > >> > 1. For a NAT middlebox, I believe, the semantics ought to cover th= e > >> following > >> > transactions. My comments assume the following. > >> > > >> > A. NAT is configured on a per-interface basis. As such, the > >> > Midcom/NAT transactions would be specified on a per-inter= face > >> basis. > >> > >> I do not share this view. A midcom agent has the intention and capab= ility > >> to specify endpoints of communication across the middlebox. Which > interfaces > >> of the middlebox are affected is not subject of midcom transactions. > > > > It would be when the middlebox has several interfaces. >=20 > Then the MIDCOM server needs to identify the proper interfaces or confi= gure > all of them. The primary goal is enabling communication between the spe= cified > end points. >=20 I understand what you say about agent wanting to enable communication bet= ween application end-points. I elieve, the agent cannot do this without the knowledge of how the middlebox is configured. How can the agent know to m= ake the NAT transactions without the knowledge of how the address maps config= ured on the middlebox? =20 > >> > >> The MIDCOM information model simplifies the network view by just > separating > >> an internal network and an external network. Whether or not the midd= lebox > has > >> one or more interfaces connected to any of them is considered an int= ernal > >> matter > >> of the middlebox. > > > > The above argument would suffice for an information model where the n= etwork > > view is merely in terms of an internal network and an external networ= k. > This > > would not be adequate on an operating middlebox. Both NAT and firewal= l > oftne >=20 > You are right. It is not adequate within the middlebox. The MIDCOM serv= er > needs to translate the higher-level information into the level required= at > the middlebox. This internally required level heavily depends on the ac= tual > implementation of the middlebox and should not be reflected by the MIDC= OM > protocol. >=20 I understand where you are coming from. However, I do believe, an agent n= eeds to be aware of the middlebox configuration and resources so it knows what= is relevant for itself. Some of the transactions could possibly be made inte= rface independent. But, I believe, that cannot be the case for all transactions= .=20 (see my NAT transaction examples). > > have interface specific configurations. midcom agent will have all th= e > > information it needs from the middlebox using per-intarface configura= tions. >=20 > We should not require all MIDCOM agents to interpret low-level configur= ation > information of any kind of firewall and NAT. Please see the comment on = this > in my previous message. >=20 Is NAT address map and default idle-timeout configuration low level, in y= our mind? If so, how do you propose to get this information at a high level? = How do you propose to reserve a bunch of addresses or TU-ports on a NAT middlebo= x without knowing where these addresses are configured? > >> > >> There is no statement in framework or requirements that oblige an ag= ent to > >> find > >> out which interfaces a middlebox is using. > >> > > > > The above two documents are agnostic to the deployment scenarios and = do not > > assume a specific type of middlebox or network configurations. >=20 > Yes. That's a feature, not a shortcoming. The MIDCOM protocol semantics= also > does not assume a specific type of middlebox or network configurations. > Consequently, the semantics are defined in a way, that firewalls and NA= Ts > share as much as possible. >=20 > >> > B. End-point below is to be refered as > >> > for a PortBind. End-point for an address Bind will be > >> > . The IP address can be V4 or V6. > >> > C. The transactions specified below can be applicable to one= or > more > >> > end-points. This will include address ranges, address > >> > wild-carding, port ranges, and port wild-carding. > >> > > >> > > >> > SetMapOwner [Full | Partial] [ Entry>] > >> > - SetMapowner may be used by an agent to cla= im > >> > ownership on a complete NAT map entry or a > >> > portion of the entry. AgentId will be set = as the > >> > owner of the entire map entry or portion > thereof. > >> > > >> > (CreateBind | CreatePortBind) > >> > End-point> > >> > - Agent specifies all the requisite Paramete= rs for > >> > Bind(s) or PortBind(s). Agent requests mid= dlebox > >> > to create a BIND and respond back with an > assigned > >> > BindId. Middlebox to validate the authoriz= ation > >> > prior to responding. > >> > > >> > (RequestCreateBind | RequestPortCreateBind) > >> > [Oddity opt= ion] > >> > - Agent requests the Middlebox to create BIN= D(s) > for > >> > the given End-point, optionally with an Od= dity > >> > requirement. Middlebox to validate the > >> > authorization, prior to assgining a BIND a= nd > >> > a BindId and returning the response. > >> > > >> > CreateOutboundSession > >> > | > >> > | Bindid> > >> > > >> > > >> > - Agent specifies all the requisite Paramete= rs for > >> > an outbound session. Agent requests middle= box > >> > to create a session as specified and respo= nd > back > >> > with an assigned BindId. > >> > The session may have one or two end-point > >> > translations. The session may be derived > directly > >> > from the address map (or) from associated > Bind-IDs. > >> > Middlebox to validate the authorization pr= ior to > >> > responding. Note, the session tuple may ha= ve > >> > wild-card elements. > >> > > >> > RequestCreateOutboundSession > >> > | > >> > | Bindid> > >> > > >> > - Agent requests the Middlebox to create an > outbound > >> > session for the given session tuple, using= one > or > >> > more map entries and/or end-point BINDs. A= gent > >> > to validate he authorization prior to resp= onding > >> > back with a new session and session-id. As > before, > >> > the session tuple may have wild-card eleme= nts. > >> > > >> > CreateInboundSession, > >> > RequestCreateInboundSession > >> > - Similar to the outbound counterparts. > >> > > >> > ModifyBindParameters > >> > [] [MaximumIdletime>] [] > >> > - These parameters may be specified either a= t Bind > >> > creation time or later. > >> > > >> > ModifySessionParameters > >> > [] [MaximumIdletime>] [] > >> > - These parameters may be specified either a= t > session > >> > creation time or later. Note, session here > refers > >> > to the NAT data sessions, not the Midcom a= gent > >> > session. > >> > > >> > In particular, I would like to mention the notion of three resourc= es > >> > a NAT middlebox and midcom agent need to be cognizant of - > >> > Address map entries, Binds and sessions. These resources may be a) > created > >> by > >> > the agent, b) created by the NAT middlebox, or c) paramaters modif= ied by > >> the > >> > agent. > >> > >> The way I see it, MIDCOM does not distinguish binding and session (a= s the > NAT > >> MIB does). > > > > Why is that? Binds and sessions must be distinguished. This is nothig= n new. > You > > might want to refer RFC 3489 as to why it is important to make this > distinction > > n the context of NAPT devices. >=20 > I do not see any contradiction with RFC 3489. >=20 > I understand that for a NAT it is important to distinguish binding and > session > (depending of the funtionality and the implementation). However, I do n= ot see > why this distinction would be an issue for a MIDCOM agent.=20 If an agent doesnt know the resources relevant to a NAT device, how do yo= u propose the agent communicate to the NAT device? A portbind does not make= sense to a symmetric NAT. It is simply meaningless to the device because, it us= es the same local tuple to bind to different public port tuples. > Again: the a= gent > requests ENABLING communication between specified end points. The reali= zation > in terms of bindings and sessions is left to the middlebox. The middleb= ox can > consider all its functionality and implementation properties when enabl= ing > the communication. >=20 Please see my note above. The semantics draft refers to binds and does no= t refer to sessions or address map entries. > >> The point is that the MIDCOM protocol is not a middlebox management > protocol, > >> but a > >> protocol that allows applications to express requests for enabling > >> communication > >> across a middlebox. > > > > Agreed. But, you cannot mandate that a middlebox to support requests = that > it is > > not capable of. Ex: If an agent creates a port-Bind-ID and expects th= is > Bind-Id >=20 > If a NAT is not capable, it just should reject the request. >=20 Well, the midcom protocol just failed to accomplish what is required of i= t. This would not have been the case had the semantics been aware of the fac= t that the NAT middlebox was not using port-binds. > > to be used for all outgoign sessions by the NAPT device, the agent is= going > to > > be disappointed on certain boxes. >=20 > What do you mean with all outgoing sessions? > The operational model defined in RFC 3303 and used for the examples in = the > semantics draft rather suggest to have a MIDCOM request per session (to= be > precisely: > here 'session' relates to application level session, not necessarily to= NAT > sessions). >=20 NAT maintains a session for every 5-tuple that traverses it.=20 > I wonder why a middlebox would not be capable of providing such fine-gr= ained > bindings. >=20 That is my point, Jurgen. Not all NAT devices provide fine-grained binds.= But, an agent needs to work with the resources a middlebox manages. > >> > >> > 2. The notion of PRR is incomplete without the context of the enti= re > >> address > >> > map entry. The reservation may not be specific to address/address-= port > >> alone. > >> > My view of this is simply that PRR is just another notion of owner= ship > >> claim. > >> > it just happens to be in relation to an address map entry. > >> > >> The intention behind PRR is just to reserve addresses at the middleb= ox. > >> This can be doen without mapping them already. > > > > Jurgen - A middlebox may have several address map entries configured = on an > > interface. Which of the entries do you refer the addresses to? Why do= you > think > > the agent shoudl be allowed to reserve addresses alone? >=20 > It is the middlebox' task to find out which address mapping is affected. > The concept of address mapping remains hidden for the MIDCOM agent. I disagree. >=20 > >> > >> > 3. When you combine the notion of PRR wth PER, the state transitio= n > diagram > >> in > >> > section 2.3.13 woudl be simplified, with the proviso that there wo= uld be > >> three > >> > types of policy rules (address map entries, binds and sessions). > >> > >> Again, binds and sessions cannot be distinguished in the midcom worl= d. > > > > Again, this is not true. Can you point me to any reference that said = this? >=20 > This is in line with RFC 3303 and 3304, although not explicitly mention= ed > there. They do not mention it.=20 > Can you point to any reference that contradicts this? Take a look at RFC 3235 - section 3.1.1 & 3.2.1. I would also suggest you to take a look at RFC 3489, section 5. >=20 > >> > >> > 4. I agree with your notion of Session establishment and session > >> termination > >> > transactions. > >> > > >> > 5. I believe, the group Ids an agent would use during the lifetime= of a > >> Midcom > >> > session should be specified by the agent - either at the midcom se= ssion > >> > establishment time or afterwards whild the midcom session is alive. > Given > >> that > >> > group-Ids are specific to an agent, it shoudl be agent's responsib= ility > to > >> > assign group IDs, not that of the middlebox's. Further, given that= there > >> are 3 > >> > >> Group IDs need to be unique per middlebox. > > > > Why is that? Groups are a convenience concept introduced for the bene= fit of > > agents and hence are relevant to midcom agents. Agents use Group Ids = to > process > > a group of resources in a unique way. As such, the midcom agents ough= t to > be > > able to select groupIds unique to itself. I donot see a reason why th= e > > uniqueness of the following tuple not be adequate? (AgentId, > > MiddleboxFunctionResourceType, GroupId). > > > >> This is hard to achieve if the agent assigns them. > > > > On the contrary, I believe the opposite. Please see my note above. >=20 > I see, agreed. But still I wonder why you say "group-Ids are specific t= o > an agent, it shoudl be agent's responsibility to assign group IDs"? >=20 > Why are group IDs specific to an agent? Well, the grouping is done by an agent for its convenience. The propertie= s for a group are set by the agent. An agent will not use or manipulate another agent's group-Id etc..=20 Middlebox has no use for groups, if agents do not need them. Given that a= n agent ID is unique, why should the middlebox be required to maintain uniq= ue group IDs across all the various agents and resource types? >=20 > They are used to address a group of rules on a certain middlebox. > So the primary requirement is having them unique per middlebox. Well, the resource entity must be owned by an agent before the entity is assigned a group ID. Given that the entity is already owned by the agent,= the agent might as well assign a group-Id as appropriate to itself. =20 >=20 > >> > >> > different types of resources (map entries, Binds and sessions), th= ere > >> shoudl be > >> > three different sets of group-Ids, one set for each resource type. > >> > Middlebox will assign a default groupId of 0 to all entities that = are > not > >> > assigned a groupId by the agent. > >> > >> I prefer to have reservation rules and enable rules (bindings) to be > >> able to share a group. > > > > Why do you need reservation rules to be able to share a group? I find= the > > reservation concept alien to NAT middleboxes. Are you talking about > transfer of > > ownership from an address map entry to BINDs? if so, I dont see that = as > > problem. If not, I donot know what you are talking about. >=20 > Several of our controversies are based on our different view points. > You look a the issues from a NAT perspective, I am looking from a MIDCO= M > agent perspective. >=20 Well, here is what I think is the difference. I look at MIDCOM as a transaction model in which an agent works with midd= lebox resources. This has been to central to all my arguments. Correct me if I= am wrong. But, I believe, you are creating an abstract model of resources (w= hich, I believe, you call as rules) and mandate middleboxes to meet that abstr= act resource model. That is the disconnect between us, in my opinion.=20 Middleboxes have been here for sometime. Midcom protocol shoudl not manda= te dramatic change in their resource model or their way of basic operation.=20 > >From an agent perspective I would like to have rules belonging to the = same > (application-level) session into one group. Then I can easily extend th= e > lifetime of all rules, when I want to extend the lifetime of the entire > session. Or I can terminate everything at once without forgetting a rul= e. >=20 > But when setting up a session, I can set up some reservation rules > immediately, for some I have to make a reservation first and wait > for more signaling messages until session setup is complete. During tha= t > time, I assign all rules to the same group. When session setup is > complete, all rules are reserve rules. This is different during initial > setup or when the session is modified while being active. Then also > reserve rules are members. If session setup fails, I can just delete > the group with all rules including reservation rules. >=20 > Of course, from a NAT point of view, this is different. There are > essential differences between reservations and bindings/sessions. > However, this difference should be kept internal. >=20 > The MIDCOM server can easily maintain groups consisting of address > reservations, NAT bindings/sessions, and firewall rules. I do not think > NAT bindings and address bindings are much more alien to each other > than NAT bindings and firewall rules are. Why is the semantics document mandating that middlebox assign and maintai= ng unique group IDs, when in fact that may merely be an implementation optio= n? Why is the semantics document mandating reservation rules for addresses a= nd ports? Why is this reservation construct more important than working wit= h the resources/objects that a NAT middlebox has ex: NAT address map entries, b= inds, sessions. =20 >=20 > Cheers, >=20 > Juergen >=20 >=20 > >> because then the agent can extend or delete > >> sets of them belonging together by just accessing a single group. > > > > I have no problem with grouping as such. I am in support of the group= ing > > concept. I see the benefit of group based handling for the midcom age= nts. > For > > this reason, I believe, the group IDs are to be assigned by the agent= s, and > not > > the middlebox. Further, I dont see how this is related to PRR reserva= tions. > > > >> > >> Cheers, > >> > >> Juergen > >> -- > >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 905= 11-15 > >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 905= 11-55 > >> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.= nec.de > >> cheers, suresh =3D=3D=3D=3D=3D _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Sep 17 09:47:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11058 for ; Wed, 17 Sep 2003 09:47:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zceB-0006yS-H3 for midcom-archive@odin.ietf.org; Wed, 17 Sep 2003 09:47:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HDl7Ex026804 for midcom-archive@odin.ietf.org; Wed, 17 Sep 2003 09:47:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zce5-0006xq-Uq; Wed, 17 Sep 2003 09:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zcd7-0006x0-H2 for midcom@optimus.ietf.org; Wed, 17 Sep 2003 09:46:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11042 for ; Wed, 17 Sep 2003 09:45:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zcd5-00066C-00 for midcom@ietf.org; Wed, 17 Sep 2003 09:45:59 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19zcd4-000662-00 for midcom@ietf.org; Wed, 17 Sep 2003 09:45:58 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.9) with ESMTP id h8HDjPgu075299; Wed, 17 Sep 2003 15:45:26 +0200 (CEST) Received: from [10.1.1.171] (m-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 62EF037833; Wed, 17 Sep 2003 15:16:32 +0200 (CEST) Date: Wed, 17 Sep 2003 15:45:56 +0200 From: Juergen Quittek To: Pyda Srisuresh , midcom@ietf.org Cc: stiemerling@ccrle.nec.de, taylor@nortelnetworks.com Subject: Re: [midcom] Reminder: wg last call Message-ID: <2147483647.1063813556@[10.1.1.171]> In-Reply-To: <20030917042425.47563.qmail@web40408.mail.yahoo.com> References: <20030917042425.47563.qmail@web40408.mail.yahoo.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Pyda, --On 16.09.2003 21:24 h -0700 Pyda Srisuresh wrote: > > --- J=B8rgen_Quittek wrote: >> Pyda, >> >> --On 15.09.2003 9:32 Uhr -0700 Pyda Srisuresh wrote: >> >> > Jurgen, >> > >> > Please see my comments below. >> > >> > regards, >> > suresh >> > >> > --- J=3Frgen_Quittek wrote: >> >> Pyda, >> >> >> >> Thanks for your comments. Please see replies to some of them inline. >> >> >> >> --On 06.09.2003 14:15 Uhr -0700 Pyda Srisuresh >> wrote: >> >> >> >> > Below is text of the e-mail (a little revised) I sent to the authors >> >> earlier. I >> >> > am including the text for wider audience. Below are my outstanding >> comments >> >> on >> >> > the draft. >> >> > >> >> > 1. For a NAT middlebox, I believe, the semantics ought to cover the >> >> following >> >> > transactions. My comments assume the following. >> >> > >> >> > A. NAT is configured on a per-interface basis. As such, the >> >> > Midcom/NAT transactions would be specified on a per-interface >> >> basis. >> >> >> >> I do not share this view. A midcom agent has the intention and capability >> >> to specify endpoints of communication across the middlebox. Which >> interfaces >> >> of the middlebox are affected is not subject of midcom transactions. >> > >> > It would be when the middlebox has several interfaces. >> >> Then the MIDCOM server needs to identify the proper interfaces or configure >> all of them. The primary goal is enabling communication between the specified >> end points. >> > > I understand what you say about agent wanting to enable communication between > application end-points. I elieve, the agent cannot do this without the > knowledge of how the middlebox is configured. How can the agent know to make > the NAT transactions without the knowledge of how the address maps configured > on the middlebox? What the agents need to know is basic topology information: which address is in which realm and which gateway connects which realms. Based on this information it can send requests to the middlebox for enabling communication between the specified endpoint addresses. Whether or not the middlebox uses address maps, bindings and fine grained sessions is not of particular interest for the agent. The MIDCOM server has the task to map the well defined high-level request to the existing configuration of the NAT or firewall. >> >> >> >> The MIDCOM information model simplifies the network view by just >> separating >> >> an internal network and an external network. Whether or not the middlebox >> has >> >> one or more interfaces connected to any of them is considered an internal >> >> matter >> >> of the middlebox. >> > >> > The above argument would suffice for an information model where the network >> > view is merely in terms of an internal network and an external network. >> This >> > would not be adequate on an operating middlebox. Both NAT and firewall >> oftne >> >> You are right. It is not adequate within the middlebox. The MIDCOM server >> needs to translate the higher-level information into the level required at >> the middlebox. This internally required level heavily depends on the actual >> implementation of the middlebox and should not be reflected by the MIDCOM >> protocol. >> > > I understand where you are coming from. However, I do believe, an agent needs > to be aware of the middlebox configuration and resources so it knows what is > relevant for itself. Why should it care about? It sends clearly defined requests and at the middlebox there is all information available that is required for fulfilling the request. > Some of the transactions could possibly be made interface > independent. But, I believe, that cannot be the case for all transactions. > (see my NAT transaction examples). Yes, the transactions may concern specific interfaces, but the middlebox has all information available to find out which are these specific ones. Why should the agent duplicate this information and try to be smarter than the middlebox itself concerning middlebox internal configuration issues? >> > have interface specific configurations. midcom agent will have all the >> > information it needs from the middlebox using per-intarface configurations. >> >> We should not require all MIDCOM agents to interpret low-level configuration >> information of any kind of firewall and NAT. Please see the comment on this >> in my previous message. >> > > Is NAT address map and default idle-timeout configuration low level, in your > mind? If so, how do you propose to get this information at a high level? How do > you propose to reserve a bunch of addresses or TU-ports on a NAT middlebox > without knowing where these addresses are configured? NAT address map yes, because it is not relevant for the MIDCOM information model. The idle timeout can be visible for the agent, when the NAT terminates an enable because the idle timeout expired. Then the MIDCOM server at the NAT needs to send a notification to all affected agents. >> >> >> >> There is no statement in framework or requirements that oblige an agent to >> >> find >> >> out which interfaces a middlebox is using. >> >> >> > >> > The above two documents are agnostic to the deployment scenarios and do not >> > assume a specific type of middlebox or network configurations. >> >> Yes. That's a feature, not a shortcoming. The MIDCOM protocol semantics also >> does not assume a specific type of middlebox or network configurations. >> Consequently, the semantics are defined in a way, that firewalls and NATs >> share as much as possible. >> [...] >> >> > >> >> > In particular, I would like to mention the notion of three resources >> >> > a NAT middlebox and midcom agent need to be cognizant of - >> >> > Address map entries, Binds and sessions. These resources may be a) >> created >> >> by >> >> > the agent, b) created by the NAT middlebox, or c) paramaters modified by >> >> the >> >> > agent. >> >> >> >> The way I see it, MIDCOM does not distinguish binding and session (as the >> NAT >> >> MIB does). >> > >> > Why is that? Binds and sessions must be distinguished. This is nothign new. >> You >> > might want to refer RFC 3489 as to why it is important to make this >> distinction >> > n the context of NAPT devices. >> >> I do not see any contradiction with RFC 3489. >> >> I understand that for a NAT it is important to distinguish binding and >> session >> (depending of the funtionality and the implementation). However, I do not see >> why this distinction would be an issue for a MIDCOM agent. > > If an agent doesnt know the resources relevant to a NAT device, how do you > propose the agent communicate to the NAT device? A portbind does not make sense > to a symmetric NAT. It is simply meaningless to the device because, it uses the > same local tuple to bind to different public port tuples. Again, the agent does not explicitly ask for a port bind. It asks for enabling communication between the specified end points! Whether or not the middlebox needs to establish a port bind for enabling communication is not really what the agent cares about. Oops, I start repeating myself: >> Again: the agent >> requests ENABLING communication between specified end points. The realization >> in terms of bindings and sessions is left to the middlebox. The middlebox can >> consider all its functionality and implementation properties when enabling >> the communication. >> > Please see my note above. The semantics draft refers to binds and does not > refer to sessions or address map entries. It looks like, here we are close to the core of our dispute: Why does the middlebox has to care about details of the way the NAT or firewall enables communication? The NAT should be smart enough to decide this by itself, particularly, since it knows and understands its own configuration much better than an agent would do. >> >> The point is that the MIDCOM protocol is not a middlebox management >> protocol, >> >> but a >> >> protocol that allows applications to express requests for enabling >> >> communication >> >> across a middlebox. >> > >> > Agreed. But, you cannot mandate that a middlebox to support requests that >> it is >> > not capable of. Ex: If an agent creates a port-Bind-ID and expects this >> Bind-Id >> >> If a NAT is not capable, it just should reject the request. >> > Well, the midcom protocol just failed to accomplish what is required of it. > This would not have been the case had the semantics been aware of the fact that > the NAT middlebox was not using port-binds. Still I see this as a problem to be solved by the NAT. Do I miss something important? >> > to be used for all outgoign sessions by the NAPT device, the agent is going >> to >> > be disappointed on certain boxes. >> >> What do you mean with all outgoing sessions? >> The operational model defined in RFC 3303 and used for the examples in the >> semantics draft rather suggest to have a MIDCOM request per session (to be >> precisely: >> here 'session' relates to application level session, not necessarily to NAT >> sessions). >> > NAT maintains a session for every 5-tuple that traverses it. Yep, that's what the agent likes. >> I wonder why a middlebox would not be capable of providing such fine-grained >> bindings. >> > That is my point, Jurgen. Not all NAT devices provide fine-grained binds. But, > an agent needs to work with the resources a middlebox manages. If they don't, they probably have other means for enabling communication between the specified endpoints, don't they? >> >> >> >> > 2. The notion of PRR is incomplete without the context of the entire >> >> address >> >> > map entry. The reservation may not be specific to address/address-port >> >> alone. >> >> > My view of this is simply that PRR is just another notion of ownership >> >> claim. >> >> > it just happens to be in relation to an address map entry. >> >> >> >> The intention behind PRR is just to reserve addresses at the middlebox. >> >> This can be doen without mapping them already. >> > >> > Jurgen - A middlebox may have several address map entries configured on an >> > interface. Which of the entries do you refer the addresses to? Why do you >> think >> > the agent shoudl be allowed to reserve addresses alone? >> >> It is the middlebox' task to find out which address mapping is affected. >> The concept of address mapping remains hidden for the MIDCOM agent. > > I disagree. How can we solve our disagreement. Your claim: - the agent needs to completely understand the entire middlebox configuration and its its way of operation (be it a firewall or a NAT or a combined device) and then determine which values it needs to write to which SNMP table (address map, bindings, firewall rules, ...). Martin's and Juergen's claim: - The request sent by the agent should be as independent as possible from actual middlebox configurations and ways of operation. The middlebox needs to translate the high level requests sent by the agent to a set of local configuration parameters. >> >> >> >> >> > 3. When you combine the notion of PRR wth PER, the state transition >> diagram >> >> in >> >> > section 2.3.13 woudl be simplified, with the proviso that there would be >> >> three >> >> > types of policy rules (address map entries, binds and sessions). >> >> >> >> Again, binds and sessions cannot be distinguished in the midcom world. >> > >> > Again, this is not true. Can you point me to any reference that said this? >> >> This is in line with RFC 3303 and 3304, although not explicitly mentioned >> there. > > They do not mention it. > >> Can you point to any reference that contradicts this? > > Take a look at RFC 3235 - section 3.1.1 & 3.2.1. > I would also suggest you to take a look at RFC 3489, section 5. I fully agree with all sections you mention. Still, I do not see how they affect our discussion. >> >> >> >> > 4. I agree with your notion of Session establishment and session >> >> termination >> >> > transactions. >> >> > >> >> > 5. I believe, the group Ids an agent would use during the lifetime of a >> >> Midcom >> >> > session should be specified by the agent - either at the midcom session >> >> > establishment time or afterwards whild the midcom session is alive. >> Given >> >> that >> >> > group-Ids are specific to an agent, it shoudl be agent's responsibility >> to >> >> > assign group IDs, not that of the middlebox's. Further, given that there >> >> are 3 >> >> >> >> Group IDs need to be unique per middlebox. >> > >> > Why is that? Groups are a convenience concept introduced for the benefit of >> > agents and hence are relevant to midcom agents. Agents use Group Ids to >> process >> > a group of resources in a unique way. As such, the midcom agents ought to >> be >> > able to select groupIds unique to itself. I donot see a reason why the >> > uniqueness of the following tuple not be adequate? (AgentId, >> > MiddleboxFunctionResourceType, GroupId). >> > >> >> This is hard to achieve if the agent assigns them. >> > >> > On the contrary, I believe the opposite. Please see my note above. >> >> I see, agreed. But still I wonder why you say "group-Ids are specific to >> an agent, it shoudl be agent's responsibility to assign group IDs"? >> >> Why are group IDs specific to an agent? > > Well, the grouping is done by an agent for its convenience. The properties for > a group are set by the agent. An agent will not use or manipulate another > agent's group-Id etc.. It will. Here is a quote from RFC 3304, section 2.2.7: The Midcom protocol must not preclude multiple authorized agents from working on the same ruleset. > Middlebox has no use for groups, if agents do not need them. Given that an > agent ID is unique, why should the middlebox be required to maintain unique > group IDs across all the various agents and resource types? See above. RFC 3304, section 2.2.7 requires this. >> They are used to address a group of rules on a certain middlebox. >> So the primary requirement is having them unique per middlebox. > > Well, the resource entity must be owned by an agent before the entity is > assigned a group ID. Given that the entity is already owned by the agent, the > agent might as well assign a group-Id as appropriate to itself. According to the semantics document, acquiring a resource and assigning it to a group is performed in a single transaction. There is no requirement for ordering them. Actually, in an early version of the SIMCO protocol the agent was required to establish a group first, before it could request resources. >> >> >> >> > different types of resources (map entries, Binds and sessions), there >> >> shoudl be >> >> > three different sets of group-Ids, one set for each resource type. >> >> > Middlebox will assign a default groupId of 0 to all entities that are >> not >> >> > assigned a groupId by the agent. >> >> >> >> I prefer to have reservation rules and enable rules (bindings) to be >> >> able to share a group. >> > >> > Why do you need reservation rules to be able to share a group? I find the >> > reservation concept alien to NAT middleboxes. Are you talking about >> transfer of >> > ownership from an address map entry to BINDs? if so, I dont see that as >> > problem. If not, I donot know what you are talking about. >> >> Several of our controversies are based on our different view points. >> You look a the issues from a NAT perspective, I am looking from a MIDCOM >> agent perspective. >> > > Well, here is what I think is the difference. > > I look at MIDCOM as a transaction model in which an agent works with middlebox > resources. This has been to central to all my arguments. Correct me if I am > wrong. But, I believe, you are creating an abstract model of resources (which, > I believe, you call as rules) and mandate middleboxes to meet that abstract > resource model. That is the disconnect between us, in my opinion. Completely agreed. > Middleboxes have been here for sometime. Midcom protocol shoudl not mandate > dramatic change in their resource model or their way of basic operation. Actually, there is no such request at all. The only request is adding a MIDCOM server to the middlebox implementing the MIDCOM protocol semantics. This does not seem to be a dramatic change of the basic operation of a middlebox. In contrary, I do not even require that the way of operation is visible outside of the middlebox. The middlebox can operate as it likes and use any resource model that is sufficient for its operation. Only the new MIDCOM server at the middlebox needs to understand the way of operation. >> > From an agent perspective I would like to have rules belonging to the same >> (application-level) session into one group. Then I can easily extend the >> lifetime of all rules, when I want to extend the lifetime of the entire >> session. Or I can terminate everything at once without forgetting a rule. >> >> But when setting up a session, I can set up some reservation rules >> immediately, for some I have to make a reservation first and wait >> for more signaling messages until session setup is complete. During that >> time, I assign all rules to the same group. When session setup is >> complete, all rules are reserve rules. This is different during initial >> setup or when the session is modified while being active. Then also >> reserve rules are members. If session setup fails, I can just delete >> the group with all rules including reservation rules. >> >> Of course, from a NAT point of view, this is different. There are >> essential differences between reservations and bindings/sessions. >> However, this difference should be kept internal. >> >> The MIDCOM server can easily maintain groups consisting of address >> reservations, NAT bindings/sessions, and firewall rules. I do not think >> NAT bindings and address bindings are much more alien to each other >> than NAT bindings and firewall rules are. > > Why is the semantics document mandating that middlebox assign and maintaing > unique group IDs, when in fact that may merely be an implementation option? They are not. They are required by RFC 3304, section 2.2.3. > Why is the semantics document mandating reservation rules for addresses and > ports? Why is this reservation construct more important than working with the > resources/objects that a NAT middlebox has ex: NAT address map entries, binds, > sessions. This a very good question. And sometimes I still wonder about that. However, I have not seen any other satisfying solution for the application scenario from which the need for this transaction was derived, see semantics section 4.2. Cheers, Martin and Juergen >> >> Cheers, >> >> Juergen >> >> >> >> because then the agent can extend or delete >> >> sets of them belonging together by just accessing a single group. >> > >> > I have no problem with grouping as such. I am in support of the grouping >> > concept. I see the benefit of group based handling for the midcom agents. >> For >> > this reason, I believe, the group IDs are to be assigned by the agents, and >> not >> > the middlebox. Further, I dont see how this is related to PRR reservations. >> > >> >> >> >> Cheers, >> >> >> >> Juergen >> >> -- >> >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >> >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >> >> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de >> >> > cheers, > suresh > > =3D=3D=3D=3D=3D _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Sep 17 13:04:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20303 for ; Wed, 17 Sep 2003 13:04:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zfiq-0006iK-OI for midcom-archive@odin.ietf.org; Wed, 17 Sep 2003 13:04:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HH48Wk025805 for midcom-archive@odin.ietf.org; Wed, 17 Sep 2003 13:04:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zfik-0006hb-3L; Wed, 17 Sep 2003 13:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zfi3-0006hL-7f for midcom@optimus.ietf.org; Wed, 17 Sep 2003 13:03:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20273 for ; Wed, 17 Sep 2003 13:03:09 -0400 (EDT) From: koranteng_ofosu-amaah@us.ibm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zfi1-00015B-00 for midcom@ietf.org; Wed, 17 Sep 2003 13:03:17 -0400 Received: from lotus.lotus.com ([129.42.250.41]) by ietf-mx with esmtp (Exim 4.12) id 19zfi0-00014T-00 for midcom@ietf.org; Wed, 17 Sep 2003 13:03:16 -0400 Received: from internet1.lotus.com (internet1 [172.16.131.235]) by lotus.lotus.com (8.12.9/8.12.9) with ESMTP id h8HGtTlH009730; Wed, 17 Sep 2003 12:55:51 -0400 (EDT) Received: from wtfmail04.lotus.com (wtfmail04.lotus.com [9.33.9.121]) by internet1.lotus.com (8.12.9/8.12.6) with ESMTP id h8HH2Bnu004738; Wed, 17 Sep 2003 13:02:11 -0400 (EDT) Subject: Re: [midcom] topology considerations again [was: Reminder: wg last call ] To: midcom@ietf.org, quittek@ccrle.nec.de, srisuresh@yahoo.com X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 Message-ID: Date: Wed, 17 Sep 2003 13:02:08 -0400 X-MIMETrack: Serialize by Router on WTFMAIL04/WTF/M/Lotus(Build V65_09142003NP|September 14, 2003) at 09/17/2003 13:02:10 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable One of the issues that J=FCrgen and Pyda are disagreeing about centers = on whether a midcom agent can, or should, have knowledge of interfaces of = the middlebox it interacts with and if the semantics of the midcom protocol= should take that into account. Paraphrasing Pyda: "NAT is configured on a per-interface basis. As su= ch, the Midcom/NAT transactions would be specified on a per-interface basis= ." Ultimately this comes to topology. This was a hot issue in this working= group 2 years ago. We had at least 3 different topology considerations documents discussing the issue. At the time, I think Melinda rather skillfully steered the group away from this weighty topic and onto the = more basic task of specifying requirements for midcom. It seems to me that we have come full circle and I sense that if we do = get into topology again, we won't be too long before we again start discuss= ing 'realms', 'in-and-out', global namespaces etc. At the same time, it is = last call for the document so we should speak up now. Some questions come to mind: Do the semantics that we have specified unnecessarily constrain the configuration of midcom agents and middleboxes to simple topology's? Do we have indeed to deal with midcom agents with multiple interfaces? Are topology considerations out-of-scope for the working group? If so, = are we really just leaving it up to implementers to deal with the topology issue in proprietary ways? Can the semantics be adapted without too much complexity to deal with topology? Do the need to be? Is our extensibility story good enough that an implementer could attac= h 'interface' information to transactions? My own review of the semantics document is that it is good enough for t= he kinds of simple uses of midcom I have in mind. I think though that it i= s reasonable to ask these questions now. We can take a look at some of the older messages (for example this one = by Andrew Molitor) to get a sense of past thinking on the topology issue http://www.ietf.org/mail-archive/working-groups/midcom/current/msg01152= .html -- Koranteng Ofosu-Amaah Portal Solutions - Lotus Software - IBM= _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Sep 17 13:37:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21265 for ; Wed, 17 Sep 2003 13:37:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zgEi-0007j3-SE for midcom-archive@odin.ietf.org; Wed, 17 Sep 2003 13:37:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HHb4oT029653 for midcom-archive@odin.ietf.org; Wed, 17 Sep 2003 13:37:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zgEg-0007hc-C9; Wed, 17 Sep 2003 13:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zgE3-0007gR-Rm for midcom@optimus.ietf.org; Wed, 17 Sep 2003 13:36:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21257 for ; Wed, 17 Sep 2003 13:36:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zgE1-0001Om-00 for midcom@ietf.org; Wed, 17 Sep 2003 13:36:21 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19zgE1-0001Od-00 for midcom@ietf.org; Wed, 17 Sep 2003 13:36:21 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8HHZnfX021362; Wed, 17 Sep 2003 10:35:49 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-43.cisco.com [10.32.241.43]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AMF75116; Wed, 17 Sep 2003 10:35:47 -0700 (PDT) Date: Wed, 17 Sep 2003 13:35:46 -0400 Subject: Re: [midcom] topology considerations again [was: Reminder: wg last call ] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: midcom@ietf.org To: koranteng_ofosu-amaah@us.ibm.com From: Melinda Shore In-Reply-To: Message-Id: <5EE651D6-E935-11D7-85E2-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wednesday, September 17, 2003, at 01:02 PM, koranteng_ofosu-amaah@us.ibm.com wrote: > Are topology considerations out-of-scope for the working group? If so, > are > we really just leaving it up to implementers to deal with the topology > issue in proprietary ways? Yes, topology considerations are out-of-scope and we're really leaving it up to implementers to deal with them. The question of specifying interfaces is inextricable from the question of pushing routing information out to the agent, which would be a terrible mistake. As I said earlier my preference would be that the request from the agent would not contain an interface identifier and that the middlebox would select one based on its own understanding of the network topology. However, the question of overlapping address spaces is a serious one, and I do think that it would be useful to allow an optional interface identifier includable in the request for dealing with this in a proprietary way. I expect it would be abused, but I don't think that's sufficient cause to refuse to include an otherwise useful protocol element. Thanks very much for pointing out the earlier discussions. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Sep 17 17:09:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29969 for ; Wed, 17 Sep 2003 17:09:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjY4-0007oV-Vw for midcom-archive@odin.ietf.org; Wed, 17 Sep 2003 17:09:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HL9GN4030010 for midcom-archive@odin.ietf.org; Wed, 17 Sep 2003 17:09:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjXr-0007n8-AK; Wed, 17 Sep 2003 17:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjXJ-0007dm-1j for midcom@optimus.ietf.org; Wed, 17 Sep 2003 17:08:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29886 for ; Wed, 17 Sep 2003 17:08:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zjXG-0003hL-00 for midcom@ietf.org; Wed, 17 Sep 2003 17:08:26 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19zjXF-0003h4-00 for midcom@ietf.org; Wed, 17 Sep 2003 17:08:26 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.9) with ESMTP id h8HL7jgu089443; Wed, 17 Sep 2003 23:07:46 +0200 (CEST) Received: by venus.office (Postfix on SuSE Linux eMail Server 3.0, from userid 30) id 78A93C90ED; Wed, 17 Sep 2003 22:38:50 +0200 (CEST) Cc: midcom@ietf.org, koranteng_ofosu-amaah@us.ibm.com X-Accept-Language: de, en X-Priority: 3 (Normal) X-Mailer: SKYRiXgreen_3.1 NGMime_4.2.45 references: <5EE651D6-E935-11D7-85E2-000A95E35274@cisco.com> From: "Juergen Quittek" MIME-Version: 1.0 subject: Re: [midcom] topology considerations again [was: Reminder: wg last call ] To: "Melinda Shore" content-type: text/plain; charset="iso-8859-1" date: Wed, 17 Sep 2003 22:38:50 +0200 content-transfer-encoding: 7bit Message-Id: <20030917203850.78A93C90ED@venus.office> X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > On Wednesday, September 17, 2003, at 01:02 PM, > koranteng_ofosu-amaah@us.ibm.com wrote: > > Are topology considerations out-of-scope for the working group? If so, > > are > > we really just leaving it up to implementers to deal with the topology > > issue in proprietary ways? > > Yes, topology considerations are out-of-scope and we're really > leaving it up to implementers to deal with them. The question of > specifying interfaces is inextricable from the question of > pushing routing information out to the agent, which would be a > terrible mistake. As I said earlier my preference would be > that the request from the agent would not contain an interface > identifier and that the middlebox would select one based on its > own understanding of the network topology. > > However, the question of overlapping address spaces is a serious > one, and I do think that it would be useful to allow an optional > interface identifier includable in the request for dealing with > this in a proprietary way. I expect it would be abused, but I > don't think that's sufficient cause to refuse to include an > otherwise useful protocol element. I do not see a problem with adding an optional parameter to the PRR and PER transactions. The parameter being optional implies that in general the middlebox should be able to handle requests not containing this parameter. It looks like we need two optional interface parameters, one for each 'side' of the middlebox? Juergen > Thanks very much for pointing out the earlier discussions. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > -- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Sep 18 05:01:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02825 for ; Thu, 18 Sep 2003 05:01:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zuf8-0004di-0m for midcom-archive@odin.ietf.org; Thu, 18 Sep 2003 05:01:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8I91Hse017834 for midcom-archive@odin.ietf.org; Thu, 18 Sep 2003 05:01:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zuer-0004d5-BS; Thu, 18 Sep 2003 05:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zueS-0004cA-AN for midcom@optimus.ietf.org; Thu, 18 Sep 2003 05:00:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02790 for ; Thu, 18 Sep 2003 05:00:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zueP-0002qC-00 for midcom@ietf.org; Thu, 18 Sep 2003 05:00:33 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19zueO-0002pu-00 for midcom@ietf.org; Thu, 18 Sep 2003 05:00:32 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.9) with ESMTP id h8I901gu003447; Thu, 18 Sep 2003 11:00:01 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C753A99AEA; Thu, 18 Sep 2003 10:31:01 +0200 (CEST) Date: Thu, 18 Sep 2003 11:00:00 +0200 From: Martin Stiemerling To: koranteng_ofosu-amaah@us.ibm.com, midcom@ietf.org, quittek@ccrle.nec.de, srisuresh@yahoo.com Subject: Re: [midcom] topology considerations again [was: Reminder: wg last call ] Message-ID: <30990000.1063875600@[10.1.1.109]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Koranteng, thanks for poiting to the old dicussions on topology issues. As Juergen has mentioned in his email, I also agree with adding an optional = interface parameter to the PRR and PER transactions, although I think that=20 a common agent implementation won't uses that. My view is that the goal of MIDCOM is actually to relief the middlebox of=20 the ALG processing burden and not to load some new burden to the ALG, as=20 the toplogoy issue would certainly do. I would imaging the smile of a SIP=20 proxy implementor that has to deal with NAT interfaces and mapping tables=20 in addition to controlling SIP transactions. Thanks Martin --On Wednesday, September 17, 2003 13:02:08 -0400=20 koranteng_ofosu-amaah@us.ibm.com wrote: | | | | | One of the issues that J=FCrgen and Pyda are disagreeing about centers on | whether a midcom agent can, or should, have knowledge of interfaces of = the | middlebox it interacts with and if the semantics of the midcom protocol | should take that into account. | | Paraphrasing Pyda: "NAT is configured on a per-interface basis. As = such, | the Midcom/NAT transactions would be specified on a per-interface basis." | | Ultimately this comes to topology. This was a hot issue in this working | group 2 years ago. We had at least 3 different topology considerations | documents discussing the issue. At the time, I think Melinda rather | skillfully steered the group away from this weighty topic and onto the | more basic task of specifying requirements for midcom. | | It seems to me that we have come full circle and I sense that if we do = get | into topology again, we won't be too long before we again start = discussing | 'realms', 'in-and-out', global namespaces etc. At the same time, it is | last call for the document so we should speak up now. | | Some questions come to mind: | | Do the semantics that we have specified unnecessarily constrain the | configuration of midcom agents and middleboxes to simple topology's? | | Do we have indeed to deal with midcom agents with multiple interfaces? | | Are topology considerations out-of-scope for the working group? If so, = are | we really just leaving it up to implementers to deal with the topology | issue in proprietary ways? | | Can the semantics be adapted without too much complexity to deal with | topology? Do the need to be? | | Is our extensibility story good enough that an implementer could attach | 'interface' information to transactions? | | My own review of the semantics document is that it is good enough for the | kinds of simple uses of midcom I have in mind. I think though that it is | reasonable to ask these questions now. | | We can take a look at some of the older messages (for example this one by | Andrew Molitor) to get a sense of past thinking on the topology issue | | http://www.ietf.org/mail-archive/working-groups/midcom/current/msg01152.h | tml | | | | -- | Koranteng Ofosu-Amaah | Portal Solutions - Lotus Software - IBM | | | _______________________________________________ | midcom mailing list | midcom@ietf.org | https://www1.ietf.org/mailman/listinfo/midcom Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Sep 18 05:05:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02889 for ; Thu, 18 Sep 2003 05:05:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zuil-0004ky-SN for midcom-archive@odin.ietf.org; Thu, 18 Sep 2003 05:05:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8I953bd018259 for midcom-archive@odin.ietf.org; Thu, 18 Sep 2003 05:05:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zuik-0004k4-Ua; Thu, 18 Sep 2003 05:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zuiA-0004jR-FC for midcom@optimus.ietf.org; Thu, 18 Sep 2003 05:04:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02877 for ; Thu, 18 Sep 2003 05:04:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zui7-0002sN-00 for midcom@ietf.org; Thu, 18 Sep 2003 05:04:23 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19zui6-0002sJ-00 for midcom@ietf.org; Thu, 18 Sep 2003 05:04:22 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.9) with ESMTP id h8I93egu003642; Thu, 18 Sep 2003 11:03:40 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id EDD288F680; Thu, 18 Sep 2003 10:34:40 +0200 (CEST) Date: Thu, 18 Sep 2003 11:03:39 +0200 From: Martin Stiemerling To: =?ISO-8859-1?Q?J=FCrgen_Quittek?= , j.schoenwaelder@iu-bremen.de, Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] Reminder: wg last call Message-ID: <35130000.1063875819@[10.1.1.109]> In-Reply-To: <2147483647.1063287950@[10.1.1.171]> References: <82278E42-DE42-11D7-BF27-000A95E35274@cisco.com> <20030904075616.GA695@iu-bremen.de> <2147483647.1063287950@[10.1.1.171]> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable --On Thursday, September 11, 2003 13:45:50 +0200 J=FCrgen Quittek=20 wrote: | Juergen, | | I understand your concerns. They can be addressed by moving transactions | Policy Rule List (PRL) and Policy Rule Status (PRS) from optional to | mandatory. | | Still I do not have a strong feeling about whether or not applying this | change. But if not one objects on the list, I'm fine with applying it to | the next version. Since there are no objections from any of the mailing list, I would say=20 that Policy Rule List (PRL) and Policy Rule Status (PRS) are going to be=20 mandatory in the semantics. Cheers Martin Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Sep 19 21:36:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00104 for ; Fri, 19 Sep 2003 21:36:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1Vh9V020140 for ; Fri, 19 Sep 2003 21:36:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JG7g88007421 for midcom-archive@odin.ietf.org; Fri, 19 Sep 2003 12:07:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nn6-0001pr-Fq; Fri, 19 Sep 2003 12:07:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nm2-0001QO-Ne for midcom@optimus.ietf.org; Fri, 19 Sep 2003 12:06:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06871 for ; Fri, 19 Sep 2003 12:06:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0BWE-0004Dr-00 for midcom@ietf.org; Thu, 18 Sep 2003 23:01:14 -0400 Received: from web40412.mail.yahoo.com ([66.218.78.109]) by ietf-mx with smtp (Exim 4.12) id 1A0BCE-0001F3-00 for midcom@ietf.org; Thu, 18 Sep 2003 22:40:34 -0400 Message-ID: <20030919024004.63534.qmail@web40412.mail.yahoo.com> Received: from [66.224.113.194] by web40412.mail.yahoo.com via HTTP; Thu, 18 Sep 2003 19:40:04 PDT Date: Thu, 18 Sep 2003 19:40:04 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] topology considerations again [was: Reminder: wg last call ] To: Juergen Quittek , Melinda Shore Cc: midcom@ietf.org, koranteng_ofosu-amaah@us.ibm.com In-Reply-To: <20030917203850.78A93C90ED@venus.office> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , That sounds good. Thanks. cheers, suresh --- Juergen Quittek wrote: > > On Wednesday, September 17, 2003, at 01:02 PM, > > koranteng_ofosu-amaah@us.ibm.com wrote: > > > Are topology considerations out-of-scope for the working group? If so, > > > are > > > we really just leaving it up to implementers to deal with the topology > > > issue in proprietary ways? > > > > Yes, topology considerations are out-of-scope and we're really > > leaving it up to implementers to deal with them. The question of > > specifying interfaces is inextricable from the question of > > pushing routing information out to the agent, which would be a > > terrible mistake. As I said earlier my preference would be > > that the request from the agent would not contain an interface > > identifier and that the middlebox would select one based on its > > own understanding of the network topology. > > > > However, the question of overlapping address spaces is a serious > > one, and I do think that it would be useful to allow an optional > > interface identifier includable in the request for dealing with > > this in a proprietary way. I expect it would be abused, but I > > don't think that's sufficient cause to refuse to include an > > otherwise useful protocol element. > > I do not see a problem with adding an optional parameter to the > PRR and PER transactions. The parameter being optional implies > that in general the middlebox should be able to handle requests > not containing this parameter. > > It looks like we need two optional interface parameters, > one for each 'side' of the middlebox? > > Juergen > > > Thanks very much for pointing out the earlier discussions. > > > > Melinda > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > -- > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sat Sep 20 09:53:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04254 for ; Sat, 20 Sep 2003 09:53:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0PSG-0006qO-Ko for midcom-archive@odin.ietf.org; Fri, 19 Sep 2003 13:54:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JHs4sU026307 for midcom-archive@odin.ietf.org; Fri, 19 Sep 2003 13:54:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nkp-000124-SC; Fri, 19 Sep 2003 12:05:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nk8-0000mN-JU for midcom@optimus.ietf.org; Fri, 19 Sep 2003 12:04:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05279 for ; Fri, 19 Sep 2003 12:04:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0HWX-0002dh-00 for midcom@ietf.org; Fri, 19 Sep 2003 05:25:57 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 1A0HTj-0001zC-00 for midcom@ietf.org; Fri, 19 Sep 2003 05:23:03 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.9) with ESMTP id h8J9MW9D050163; Fri, 19 Sep 2003 11:22:32 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id F1C1EC4839; Fri, 19 Sep 2003 10:53:22 +0200 (CEST) Date: Fri, 19 Sep 2003 11:21:18 +0200 From: Martin Stiemerling To: Tom Taylor , =?ISO-8859-1?Q?J=FCrgen_Quittek?= Cc: Pyda Srisuresh , midcom@ietf.org Subject: Re: [midcom] Reminder: wg last call Message-ID: <6635030.1063970478@[10.1.1.109]> In-Reply-To: <3F6A49C8.9070106@nortelnetworks.com> References: <20030906211547.79199.qmail@web40401.mail.yahoo.com> <2147483647.1063288853@[10.1.1.171]> <3F6A49C8.9070106@nortelnetworks.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable --On Donnerstag, 18. September 2003 20:11 -0400 Tom Taylor=20 wrote: | I support J=FCrgen in this, but it raises a couple of interesting points. | The first is that the aims of the NAT MIB and the MIDCOM "whatever" are | different, because the target users are different. The NAT MIB is | primarily there for administrators, while the MIDCOM "whatever" is for | authorized hosts (MIDCOM agents) supporting applications. The objects of | interest are going to differ as a consequence. | | The second point is partly independent of this: my preference as a | "semantics" author to take an abstract view of firewall and NAT | operation, with the aim of avoiding as much as possible the need to know | what services the middlebox supports, is in definite contrast to the | content of the current NAT and firewall MIBs. I am not surprised to find | MIB designers scratching their heads over how to reconcile the two points | of view. My natural and naive inclination is to view the MIDCOM MIB as a | logically separate beast. The NAT or firewall MIB would merely reflect | the results of MIDCOM operations, rather than be tied to the MIDCOM MIB | explicitly. Hi Tom, I fully agree with your view that MIDCOM MIB and NAT MIB should be on two=20 different levels, the MIDCOM MIB for agents and NAT MIB for system=20 administrators. However, in the design team I'm the only one who is sharing this view, most = of the others are more in favour of implementing the MIDCOM MIB on the same = level as the NAT MIB. This issue is a fundamental one and depending on the choice the design of=20 the MIB may vary significantly. Cheers, Martin | | I suppose the question is whether the abstract view is acceptable to | implementors, or whether they will insist that any MIDCOM protocol | addresses precisely the functions offered by their middlebox. If Pyda is | representative of NAT implementors, the semantics need a bit of | modification. | | J=FCrgen Quittek wrote: | |> Pyda, |> |> Thanks for your comments. Please see replies to some of them inline. |> |> --On 06.09.2003 14:15 Uhr -0700 Pyda Srisuresh |> wrote: |> |>> Below is text of the e-mail (a little revised) I sent to the authors |>> earlier. I |>> am including the text for wider audience. Below are my outstanding |>> comments on |>> the draft. |>> |>> 1. For a NAT middlebox, I believe, the semantics ought to cover the |>> following |>> transactions. My comments assume the following. |>> |>> A. NAT is configured on a per-interface basis. As such, the |>> Midcom/NAT transactions would be specified on a per-interface |>> basis. |> |> |> I do not share this view. A midcom agent has the intention and = capability |> to specify endpoints of communication across the middlebox. Which |> interfaces |> of the middlebox are affected is not subject of midcom transactions. |> |> The MIDCOM information model simplifies the network view by just |> separating an internal network and an external network. Whether or not |> the middlebox has |> one or more interfaces connected to any of them is considered an |> internal matter |> of the middlebox. |> |> There is no statement in framework or requirements that oblige an agent |> to find |> out which interfaces a middlebox is using. |> |>> B. End-point below is to be refered as |>> for a PortBind. End-point for an address Bind will be |>> . The IP address can be V4 or V6. |>> C. The transactions specified below can be applicable to one or |>> more |>> end-points. This will include address ranges, address |>> wild-carding, port ranges, and port wild-carding. |>> |>> |>> SetMapOwner [Full | Partial] [> Entry>] |>> - SetMapowner may be used by an agent to claim |>> ownership on a complete NAT map entry or a |>> portion of the entry. AgentId will be set as = the |>> owner of the entire map entry or portion |>> thereof. |>> |>> (CreateBind | CreatePortBind) |>> > End-point> |>> - Agent specifies all the requisite Parameters = for |>> Bind(s) or PortBind(s). Agent requests = middlebox |>> to create a BIND and respond back with an |>> assigned |>> BindId. Middlebox to validate the authorization |>> prior to responding. |>> |>> (RequestCreateBind | RequestPortCreateBind) |>> [Oddity option] |>> - Agent requests the Middlebox to create BIND(s) |>> for |>> the given End-point, optionally with an Oddity |>> requirement. Middlebox to validate the |>> authorization, prior to assgining a BIND and |>> a BindId and returning the response. |>> |>> CreateOutboundSession |>> | |>> | > Bindid> |>> |>> |>> - Agent specifies all the requisite Parameters = for |>> an outbound session. Agent requests middlebox |>> to create a session as specified and respond |>> back with an assigned BindId. |>> The session may have one or two end-point |>> translations. The session may be derived |>> directly from the address map (or) from |>> associated |>> Bind-IDs. |>> Middlebox to validate the authorization prior = to |>> responding. Note, the session tuple may have |>> wild-card elements. |>> |>> RequestCreateOutboundSession |>> | |>> | > Bindid> |>> |>> - Agent requests the Middlebox to create an |>> outbound |>> session for the given session tuple, using one |>> or more map entries and/or end-point BINDs. |>> Agent to validate he authorization prior to |>> responding back with a new session and |>> session-id. As |>> before, |>> the session tuple may have wild-card elements. |>> |>> CreateInboundSession, |>> RequestCreateInboundSession |>> - Similar to the outbound counterparts. |>> |>> ModifyBindParameters |>> [] [MaximumIdletime>] [] |>> - These parameters may be specified either at = Bind |>> creation time or later. |>> |>> ModifySessionParameters |>> [] [MaximumIdletime>] [] |>> - These parameters may be specified either at |>> session |>> creation time or later. Note, session here |>> refers to the NAT data sessions, not the Midcom |>> agent session. |>> |>> In particular, I would like to mention the notion of three resources |>> a NAT middlebox and midcom agent need to be cognizant of - |>> Address map entries, Binds and sessions. These resources may be a) |>> created by |>> the agent, b) created by the NAT middlebox, or c) paramaters modified |>> by the |>> agent. |> |> |> The way I see it, MIDCOM does not distinguish binding and session (as |> the NAT MIB does). |> The point is that the MIDCOM protocol is not a middlebox management |> protocol, but a |> protocol that allows applications to express requests for enabling |> communication |> across a middlebox. |> |>> 2. The notion of PRR is incomplete without the context of the entire |>> address |>> map entry. The reservation may not be specific to address/address-port |>> alone. |>> My view of this is simply that PRR is just another notion of ownership |>> claim. |>> it just happens to be in relation to an address map entry. |> |> |> The intention behind PRR is just to reserve addresses at the middlebox. |> This can be doen without mapping them already. |> |>> 3. When you combine the notion of PRR wth PER, the state transition |>> diagram in |>> section 2.3.13 woudl be simplified, with the proviso that there would |>> be three |>> types of policy rules (address map entries, binds and sessions). |> |> |> Again, binds and sessions cannot be distinguished in the midcom world. |> |>> 4. I agree with your notion of Session establishment and session |>> termination |>> transactions. |>> |>> 5. I believe, the group Ids an agent would use during the lifetime of |>> a Midcom |>> session should be specified by the agent - either at the midcom session |>> establishment time or afterwards whild the midcom session is alive. |>> Given that |>> group-Ids are specific to an agent, it shoudl be agent's |>> responsibility to |>> assign group IDs, not that of the middlebox's. Further, given that |>> there are 3 |> |> |> Group IDs need to be unique per middlebox. |> This is hard to achieve if the agent assigns them. |> |>> different types of resources (map entries, Binds and sessions), there |>> shoudl be |>> three different sets of group-Ids, one set for each resource type. |>> Middlebox will assign a default groupId of 0 to all entities that are |>> not assigned a groupId by the agent. |> |> |> I prefer to have reservation rules and enable rules (bindings) to be |> able to share a group. because then the agent can extend or delete |> sets of them belonging together by just accessing a single group. |> |> Cheers, |> |> Juergen | Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sat Sep 20 09:53:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04302 for ; Sat, 20 Sep 2003 09:53:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0P61-00051i-81 for midcom-archive@odin.ietf.org; Fri, 19 Sep 2003 13:31:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JHV55N019321 for midcom-archive@odin.ietf.org; Fri, 19 Sep 2003 13:31:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0P5y-00050v-Tm; Fri, 19 Sep 2003 13:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Ojq-0001V2-Lp for midcom@optimus.ietf.org; Fri, 19 Sep 2003 13:08:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07356 for ; Fri, 19 Sep 2003 12:06:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A096c-0007fv-00 for midcom@ietf.org; Thu, 18 Sep 2003 20:26:38 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A08t9-0005i2-00 for midcom@ietf.org; Thu, 18 Sep 2003 20:12:43 -0400 Received: from zcard307.ca.nortel.com (americasm07.nt.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8J0BwJ12906; Thu, 18 Sep 2003 20:11:59 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZXG0H4B; Thu, 18 Sep 2003 20:11:59 -0400 Received: from nortelnetworks.com (acart1cn.ca.nortel.com [47.129.129.64]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5M600; Thu, 18 Sep 2003 20:11:59 -0400 Message-ID: <3F6A49C8.9070106@nortelnetworks.com> Date: Thu, 18 Sep 2003 20:11:52 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: =?ISO-8859-1?Q?J=FCrgen_Quittek?= CC: Pyda Srisuresh , midcom@ietf.org, stiemerling@ccrle.nec.de Subject: Re: [midcom] Reminder: wg last call References: <20030906211547.79199.qmail@web40401.mail.yahoo.com> <2147483647.1063288853@[10.1.1.171]> In-Reply-To: <2147483647.1063288853@[10.1.1.171]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by zcars04f.nortelnetworks.com id h8J0BwJ12906 Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I support J=FCrgen in this, but it raises a couple of interesting points.= The first=20 is that the aims of the NAT MIB and the MIDCOM "whatever" are different, = because the=20 target users are different. The NAT MIB is primarily there for administr= ators,=20 while the MIDCOM "whatever" is for authorized hosts (MIDCOM agents) suppo= rting=20 applications. The objects of interest are going to differ as a consequen= ce. The second point is partly independent of this: my preference as a "seman= tics"=20 author to take an abstract view of firewall and NAT operation, with the a= im of=20 avoiding as much as possible the need to know what services the middlebox= supports,=20 is in definite contrast to the content of the current NAT and firewall MI= Bs. I am=20 not surprised to find MIB designers scratching their heads over how to re= concile the=20 two points of view. My natural and naive inclination is to view the MIDC= OM MIB as a=20 logically separate beast. The NAT or firewall MIB would merely reflect t= he results=20 of MIDCOM operations, rather than be tied to the MIDCOM MIB explicitly. I suppose the question is whether the abstract view is acceptable to impl= ementors,=20 or whether they will insist that any MIDCOM protocol addresses precisely = the=20 functions offered by their middlebox. If Pyda is representative of NAT=20 implementors, the semantics need a bit of modification. J=FCrgen Quittek wrote: > Pyda, >=20 > Thanks for your comments. Please see replies to some of them inline. >=20 > --On 06.09.2003 14:15 Uhr -0700 Pyda Srisuresh wr= ote: >=20 >> Below is text of the e-mail (a little revised) I sent to the authors=20 >> earlier. I >> am including the text for wider audience. Below are my outstanding=20 >> comments on >> the draft. >> >> 1. For a NAT middlebox, I believe, the semantics ought to cover the=20 >> following >> transactions. My comments assume the following. >> >> A. NAT is configured on a per-interface basis. As such, the >> Midcom/NAT transactions would be specified on a per-interface= =20 >> basis. >=20 >=20 > I do not share this view. A midcom agent has the intention and capabili= ty > to specify endpoints of communication across the middlebox. Which=20 > interfaces > of the middlebox are affected is not subject of midcom transactions. >=20 > The MIDCOM information model simplifies the network view by just separa= ting > an internal network and an external network. Whether or not the=20 > middlebox has > one or more interfaces connected to any of them is considered an=20 > internal matter > of the middlebox. >=20 > There is no statement in framework or requirements that oblige an agent= =20 > to find > out which interfaces a middlebox is using. >=20 >> B. End-point below is to be refered as >> for a PortBind. End-point for an address Bind will be >> . The IP address can be V4 or V6. >> C. The transactions specified below can be applicable to one or=20 >> more >> end-points. This will include address ranges, address >> wild-carding, port ranges, and port wild-carding. >> >> >> SetMapOwner [Full | Partial] [> Entry>] >> - SetMapowner may be used by an agent to claim >> ownership on a complete NAT map entry or a >> portion of the entry. AgentId will be set as t= he >> owner of the entire map entry or portion there= of. >> >> (CreateBind | CreatePortBind) >> > End-point> >> - Agent specifies all the requisite Parameters f= or >> Bind(s) or PortBind(s). Agent requests middleb= ox >> to create a BIND and respond back with an=20 >> assigned >> BindId. Middlebox to validate the authorizatio= n >> prior to responding. >> >> (RequestCreateBind | RequestPortCreateBind) >> [Oddity option] >> - Agent requests the Middlebox to create BIND(s)= =20 >> for >> the given End-point, optionally with an Oddity >> requirement. Middlebox to validate the >> authorization, prior to assgining a BIND and >> a BindId and returning the response. >> >> CreateOutboundSession >> | >> | > Bindid> >> >> >> - Agent specifies all the requisite Parameters f= or >> an outbound session. Agent requests middlebox >> to create a session as specified and respond b= ack >> with an assigned BindId. >> The session may have one or two end-point >> translations. The session may be derived direc= tly >> from the address map (or) from associated=20 >> Bind-IDs. >> Middlebox to validate the authorization prior = to >> responding. Note, the session tuple may have >> wild-card elements. >> >> RequestCreateOutboundSession >> | >> | > Bindid> >> >> - Agent requests the Middlebox to create an=20 >> outbound >> session for the given session tuple, using one= or >> more map entries and/or end-point BINDs. Agent >> to validate he authorization prior to respondi= ng >> back with a new session and session-id. As=20 >> before, >> the session tuple may have wild-card elements. >> >> CreateInboundSession, >> RequestCreateInboundSession >> - Similar to the outbound counterparts. >> >> ModifyBindParameters >> [] [MaximumIdletime>] [] >> - These parameters may be specified either at Bi= nd >> creation time or later. >> >> ModifySessionParameters >> [] [MaximumIdletime>] [] >> - These parameters may be specified either at=20 >> session >> creation time or later. Note, session here ref= ers >> to the NAT data sessions, not the Midcom agent >> session. >> >> In particular, I would like to mention the notion of three resources >> a NAT middlebox and midcom agent need to be cognizant of - >> Address map entries, Binds and sessions. These resources may be a)=20 >> created by >> the agent, b) created by the NAT middlebox, or c) paramaters modified=20 >> by the >> agent. >=20 >=20 > The way I see it, MIDCOM does not distinguish binding and session (as=20 > the NAT MIB does). > The point is that the MIDCOM protocol is not a middlebox management=20 > protocol, but a > protocol that allows applications to express requests for enabling=20 > communication > across a middlebox. >=20 >> 2. The notion of PRR is incomplete without the context of the entire=20 >> address >> map entry. The reservation may not be specific to address/address-port= =20 >> alone. >> My view of this is simply that PRR is just another notion of ownership= =20 >> claim. >> it just happens to be in relation to an address map entry. >=20 >=20 > The intention behind PRR is just to reserve addresses at the middlebox. > This can be doen without mapping them already. >=20 >> 3. When you combine the notion of PRR wth PER, the state transition=20 >> diagram in >> section 2.3.13 woudl be simplified, with the proviso that there would=20 >> be three >> types of policy rules (address map entries, binds and sessions). >=20 >=20 > Again, binds and sessions cannot be distinguished in the midcom world. >=20 >> 4. I agree with your notion of Session establishment and session=20 >> termination >> transactions. >> >> 5. I believe, the group Ids an agent would use during the lifetime of=20 >> a Midcom >> session should be specified by the agent - either at the midcom sessio= n >> establishment time or afterwards whild the midcom session is alive.=20 >> Given that >> group-Ids are specific to an agent, it shoudl be agent's=20 >> responsibility to >> assign group IDs, not that of the middlebox's. Further, given that=20 >> there are 3 >=20 >=20 > Group IDs need to be unique per middlebox. > This is hard to achieve if the agent assigns them. >=20 >> different types of resources (map entries, Binds and sessions), there=20 >> shoudl be >> three different sets of group-Ids, one set for each resource type. >> Middlebox will assign a default groupId of 0 to all entities that are = not >> assigned a groupId by the agent. >=20 >=20 > I prefer to have reservation rules and enable rules (bindings) to be > able to share a group. because then the agent can extend or delete > sets of them belonging together by just accessing a single group. >=20 > Cheers, >=20 > Juergen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sat Sep 20 09:53:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04337 for ; Sat, 20 Sep 2003 09:53:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Oy5-0003t9-Pm for midcom-archive@odin.ietf.org; Fri, 19 Sep 2003 13:22:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JHMrYL014941 for midcom-archive@odin.ietf.org; Fri, 19 Sep 2003 13:22:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nko-00011m-NX; Fri, 19 Sep 2003 12:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nk2-0000fG-MT for midcom@optimus.ietf.org; Fri, 19 Sep 2003 12:04:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05026 for ; Fri, 19 Sep 2003 12:03:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0IAx-0002Ok-00 for midcom@ietf.org; Fri, 19 Sep 2003 06:07:43 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 1A0Hrh-0006Dp-00 for midcom@ietf.org; Fri, 19 Sep 2003 05:47:49 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.9) with ESMTP id h8J9lJ9D052033; Fri, 19 Sep 2003 11:47:19 +0200 (CEST) Received: from [10.1.1.171] (m-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 39855C4693; Fri, 19 Sep 2003 11:18:08 +0200 (CEST) Date: Fri, 19 Sep 2003 11:47:51 +0200 From: Juergen Quittek To: Tom Taylor Cc: Pyda Srisuresh , midcom@ietf.org, stiemerling@ccrle.nec.de Subject: Re: [midcom] Reminder: wg last call Message-ID: <2147483647.1063972071@[10.1.1.171]> In-Reply-To: <3F6A49C8.9070106@nortelnetworks.com> References: <20030906211547.79199.qmail@web40401.mail.yahoo.com> <2147483647.1063288853@[10.1.1.171]> <3F6A49C8.9070106@nortelnetworks.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Tom, --On 18.09.2003 20:11 Uhr -0400 Tom Taylor wrote: > I support J=FCrgen in this, but it raises a couple of interesting > points. The first is that the aims of the NAT MIB and the MIDCOM > "whatever" are different, because the target users are different. > The NAT MIB is primarily there for administrators, while the MIDCOM > "whatever" is for authorized hosts (MIDCOM agents) supporting > applications. The objects of interest are going to differ as a > consequence. > > The second point is partly independent of this: my preference as > a "semantics" author to take an abstract view of firewall and NAT > operation, with the aim of avoiding as much as possible the need> > to know what services the middlebox supports, is in definite > contrast to the content of the current NAT and firewall MIBs. > I am not surprised to find MIB designers scratching their heads > over how to reconcile the two points of view. My natural and > naive inclination is to view the MIDCOM MIB as a logically > separate beast. The NAT or firewall MIB would merely reflect the > results of MIDCOM operations, rather than be tied to the MIDCOM > MIB explicitly. I share this view. The MIDCOM MIB should allow the agent to specify requests on a higher level (i.e. with much less detail) than for example the NAT MIB would require. A consequence step based on this view would be to specify the MIDCOM MIB straight forward according to the semantics document. A straight forward MIB would define a table per major section in the semantics: A session table, a policy rule table and a group table plus some scalars (or a small additional table) for the middlebox capabilities. And this would be all. This would most probably simplify and speed up the MIB definition and based on this approach, we could have a first draft very soon. Juergen > I suppose the question is whether the abstract view is acceptable > to implementors, or whether they will insist that any MIDCOM > protocol addresses precisely the functions offered by their > middlebox. If Pyda is representative of NAT implementors, the > semantics need a bit of modification. > > J=FCrgen Quittek wrote: > >> Pyda, >> >> Thanks for your comments. Please see replies to some of them inline. >> >> --On 06.09.2003 14:15 Uhr -0700 Pyda Srisuresh wrote: >> >>> Below is text of the e-mail (a little revised) I sent to the authors >>> earlier. I >>> am including the text for wider audience. Below are my outstanding >>> comments on >>> the draft. >>> >>> 1. For a NAT middlebox, I believe, the semantics ought to cover the >>> following >>> transactions. My comments assume the following. >>> >>> A. NAT is configured on a per-interface basis. As such, the >>> Midcom/NAT transactions would be specified on a per-interface >>> basis. >> >> >> I do not share this view. A midcom agent has the intention and capability >> to specify endpoints of communication across the middlebox. Which >> interfaces >> of the middlebox are affected is not subject of midcom transactions. >> >> The MIDCOM information model simplifies the network view by just separating >> an internal network and an external network. Whether or not the >> middlebox has >> one or more interfaces connected to any of them is considered an >> internal matter >> of the middlebox. >> >> There is no statement in framework or requirements that oblige an agent >> to find >> out which interfaces a middlebox is using. >> >>> B. End-point below is to be refered as >>> for a PortBind. End-point for an address Bind will be >>> . The IP address can be V4 or V6. >>> C. The transactions specified below can be applicable to one or >>> more >>> end-points. This will include address ranges, address >>> wild-carding, port ranges, and port wild-carding. >>> >>> >>> SetMapOwner [Full | Partial] [>> Entry>] >>> - SetMapowner may be used by an agent to claim >>> ownership on a complete NAT map entry or a >>> portion of the entry. AgentId will be set as the >>> owner of the entire map entry or portion thereof. >>> >>> (CreateBind | CreatePortBind) >>> >> End-point> >>> - Agent specifies all the requisite Parameters for >>> Bind(s) or PortBind(s). Agent requests middlebox >>> to create a BIND and respond back with an >>> assigned >>> BindId. Middlebox to validate the authorization >>> prior to responding. >>> >>> (RequestCreateBind | RequestPortCreateBind) >>> [Oddity option] >>> - Agent requests the Middlebox to create BIND(s) >>> for >>> the given End-point, optionally with an Oddity >>> requirement. Middlebox to validate the >>> authorization, prior to assgining a BIND and >>> a BindId and returning the response. >>> >>> CreateOutboundSession >>> | >>> | >> Bindid> >>> >>> >>> - Agent specifies all the requisite Parameters for >>> an outbound session. Agent requests middlebox >>> to create a session as specified and respond back >>> with an assigned BindId. >>> The session may have one or two end-point >>> translations. The session may be derived directly >>> from the address map (or) from associated >>> Bind-IDs. >>> Middlebox to validate the authorization prior to >>> responding. Note, the session tuple may have >>> wild-card elements. >>> >>> RequestCreateOutboundSession >>> | >>> | >> Bindid> >>> >>> - Agent requests the Middlebox to create an >>> outbound >>> session for the given session tuple, using one or >>> more map entries and/or end-point BINDs. Agent >>> to validate he authorization prior to responding >>> back with a new session and session-id. As >>> before, >>> the session tuple may have wild-card elements. >>> >>> CreateInboundSession, >>> RequestCreateInboundSession >>> - Similar to the outbound counterparts. >>> >>> ModifyBindParameters >>> [] [MaximumIdletime>] [] >>> - These parameters may be specified either at Bind >>> creation time or later. >>> >>> ModifySessionParameters >>> [] [MaximumIdletime>] [] >>> - These parameters may be specified either at >>> session >>> creation time or later. Note, session here refers >>> to the NAT data sessions, not the Midcom agent >>> session. >>> >>> In particular, I would like to mention the notion of three resources >>> a NAT middlebox and midcom agent need to be cognizant of - >>> Address map entries, Binds and sessions. These resources may be a) >>> created by >>> the agent, b) created by the NAT middlebox, or c) paramaters modified >>> by the >>> agent. >> >> >> The way I see it, MIDCOM does not distinguish binding and session (as >> the NAT MIB does). >> The point is that the MIDCOM protocol is not a middlebox management >> protocol, but a >> protocol that allows applications to express requests for enabling >> communication >> across a middlebox. >> >>> 2. The notion of PRR is incomplete without the context of the entire >>> address >>> map entry. The reservation may not be specific to address/address-port >>> alone. >>> My view of this is simply that PRR is just another notion of ownership >>> claim. >>> it just happens to be in relation to an address map entry. >> >> >> The intention behind PRR is just to reserve addresses at the middlebox. >> This can be doen without mapping them already. >> >>> 3. When you combine the notion of PRR wth PER, the state transition >>> diagram in >>> section 2.3.13 woudl be simplified, with the proviso that there would >>> be three >>> types of policy rules (address map entries, binds and sessions). >> >> >> Again, binds and sessions cannot be distinguished in the midcom world. >> >>> 4. I agree with your notion of Session establishment and session >>> termination >>> transactions. >>> >>> 5. I believe, the group Ids an agent would use during the lifetime of >>> a Midcom >>> session should be specified by the agent - either at the midcom session >>> establishment time or afterwards whild the midcom session is alive. >>> Given that >>> group-Ids are specific to an agent, it shoudl be agent's >>> responsibility to >>> assign group IDs, not that of the middlebox's. Further, given that >>> there are 3 >> >> >> Group IDs need to be unique per middlebox. >> This is hard to achieve if the agent assigns them. >> >>> different types of resources (map entries, Binds and sessions), there >>> shoudl be >>> three different sets of group-Ids, one set for each resource type. >>> Middlebox will assign a default groupId of 0 to all entities that are not >>> assigned a groupId by the agent. >> >> >> I prefer to have reservation rules and enable rules (bindings) to be >> able to share a group. because then the agent can extend or delete >> sets of them belonging together by just accessing a single group. >> >> Cheers, >> >> Juergen > --=20 Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sat Sep 20 14:23:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18314 for ; Sat, 20 Sep 2003 14:23:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0mNu-0005gI-B5 for midcom-archive@odin.ietf.org; Sat, 20 Sep 2003 14:23:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KIN6Cs021837 for midcom-archive@odin.ietf.org; Sat, 20 Sep 2003 14:23:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0mNp-0005fl-0B; Sat, 20 Sep 2003 14:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0mNh-0005fa-N6 for midcom@optimus.ietf.org; Sat, 20 Sep 2003 14:22:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18311 for ; Sat, 20 Sep 2003 14:22:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0mNf-0007UE-00 for midcom@ietf.org; Sat, 20 Sep 2003 14:22:51 -0400 Received: from web40412.mail.yahoo.com ([66.218.78.109]) by ietf-mx with smtp (Exim 4.12) id 1A0mNU-0007Su-00 for midcom@ietf.org; Sat, 20 Sep 2003 14:22:40 -0400 Message-ID: <20030920182150.12453.qmail@web40412.mail.yahoo.com> Received: from [67.164.29.130] by web40412.mail.yahoo.com via HTTP; Sat, 20 Sep 2003 11:21:50 PDT Date: Sat, 20 Sep 2003 11:21:50 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Reminder: wg last call To: Tom Taylor , "Jürgen_Quittek" Cc: Pyda Srisuresh , midcom@ietf.org, stiemerling@ccrle.nec.de In-Reply-To: <3F6A49C8.9070106@nortelnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA18312 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable --- Tom Taylor wrote: > I support J=FCrgen in this, but it raises a couple of interesting point= s. The Well, it is good to agree on what we disagree about. The differences in o= ur view of Midcom semantics is that I look at Midcom as a transaction model = in which an agent works with middlebox resources. Whereas, you created an abstract model of resources(which, you call as rules) and mandate middle= boxes to meet that abstract resource model. That is the disconnect between us. > first=20 > is that the aims of the NAT MIB and the MIDCOM "whatever" are different= , > because the=20 > target users are different. The NAT MIB is primarily there for > administrators,=20 > while the MIDCOM "whatever" is for authorized hosts (MIDCOM agents) > supporting=20 > applications. The objects of interest are going to differ as a consequ= ence. >=20 The midcom semantics is transaction oriented to accomplish application sp= ecific end-2-end session setup. The transactions are directed to a middlebox. Fo= r this reason, the transactions (and hence the agents) must have a knowledge of middlebox configuration. This is independent of whether the middlebox is configured using a MIB or other means. One outcome we agreed on just rece= ntly (in a different thread) as a result is the need for interface argument in midcom transactions. > The second point is partly independent of this: my preference as a > "semantics"=20 > author to take an abstract view of firewall and NAT operation, with the= aim > of=20 > avoiding as much as possible the need to know what services the middleb= ox > supports,=20 > is in definite contrast to the content of the current NAT and firewall = MIBs.=20 Please see my note above.=20 The abstract transaction model in the semantics draft has shortcomings.=20 a) PRR/PER will only work in simplest of configurations. b) The transaction model, as specified, imposes rather unnecessarily comp= lex and yet times, impossible task on the middlebox. Let us consider the "PRR" transaction (section 2.3.7). PRR is supposed to reserve an address or a port number range. This might work in the case th= e middlebox has just one map entry in the address map (say 0.0.0.0/0 -> X1 = or 0.0.0.0/0 -> X2/n). This will fail the moment the address map has multipl= e map entries. Further, an address or port-range reservation is meaningful only= in the context of an address map entry. Say, you had 3 address map entries a= s follows. 10.1.0.0/16 -> X1/24;=20 10.2.5.0/24 -> X2/28;=20 0.0.0.0/0 -> X3; Say, PRR made a request for an address without the context of a map entry= . Say, the middlebox responded back with an address in X1 range. This address wo= uld be meaningless to the agent, if the agent happens to be using an address out= side the range of 10.1.0.0/16. So, the PRR request ought to specify the addres= s map entry from which the request is beign made.=20 Even if the agent was using an address in the range of 10.1.0.0/16 - say, 10.1.0.1, and the agent obtains an address, say X1.1, the middlebox has = no way to know that all sessions from 10.1.0.1 have to be bound to X1.1. The age= nt might create a BIND (using PER) at a later time. But, prior to this, if N= AT sees any session originating from 10.1.0.1, it would bind the address to = one of the available addresses within X1/8 (different from X1.1, as X1.1 is rese= ved by an agent). Now, lots of chaos ensues because, the PER from the agent woul= d fail. This is why I suggested the tansaction "SetMapOwner [Full | Partial] []" to claim full/partial ownership= of an address map entry unequivocally. This is fully contextual and there are n= o race conditions between the agent and the middlebox. Now, let us consider the case of PER transaction(section 2.3.8). PER in t= he context of a NAT refers to the agent creating a NAT binding with specific parameters. This will fail if the prameters specified in the bind-create request donot correspond to one or more (in the case of twice-NAT) addres= s map entries. Without reference of an address map entry, the agent has no know= ledge of whether to request for an address bind or a port bind. Further, the bi= nding is meaningless without the exact session description to a symmetric NAPT.= This is because symmetric NAPT uses different port bindings for the same (priv= ate IP address, port) tuple used in different sessions. The port bind may work o= nly for the first session that originates from (provate IP address, port). Th= ere are other caveats. Without a PRR preceding the PER, how is the PER to kno= w what external address to bound to? Why not let the middlebox select the extern= al address to bound to?=20 This is why I suggested the tansactions CreateBind, CreateportBind, RequestCreateBind, and RequestCreatePortBind to create binds unequivocall= y. These transactions use address map as an argument. Either the agent or th= e middlebox can create a bind.=20 Creating binds is not adequate. The agent needs to be able to specify the permitted sessions as well. Without going into the details, i will simply suggest FTP(TCP based) and TFTP(UDP based) are examples of this. This is why I suggested the tansactions CreateOutboundSesion, CreateInboundSession, RequestCreateOutboundSession and RequestCreateInboundSession to create sessions unequivocally. Either the = agent or the middlebox can create a session. As for twice-NAT, I am frankly confused by the PRR/PER transactions. Ther= e was reference to using a singe policy rule identifier for two address/port reservations and two binds. Assuming all the parameters specified in a PE= R are adequate (which I dont believe, they are), the requirement of using a new artificial handle to represent two independent twice-nat bind is unnecess= arily complex on the part of the middlebox. > I am=20 > not surprised to find MIB designers scratching their heads over how to > reconcile the=20 > two points of view.=20 MIB designers donot have a problem creating a MIB to run transactions. MI= B designers are having to scratch their head because the Midcom semantics w= orks only in the simplest of cases.=20 > My natural and naive inclination is to view the MID= COM > MIB as a=20 > logically separate beast. The NAT or firewall MIB would merely reflect= the > results=20 > of MIDCOM operations, rather than be tied to the MIDCOM MIB explicitly. I donot have a problem provided the the midcom transactions are reasonabl= e, complete and donot impose impossible requirements on the middleboxes. It = is my view that the transactions are most meanigful when the transactions relat= e to the resources/objects the middlebox can relate to. >=20 > I suppose the question is whether the abstract view is acceptable to > implementors,=20 > or whether they will insist that any MIDCOM protocol addresses precisel= y the=20 > functions offered by their middlebox. If Pyda is representative of NAT= =20 > implementors, the semantics need a bit of modification. I do believe, the transactions in the semantics document need modificatio= n. If you like, I would be glad to work with the authors on this. regards, suresh >=20 > J=FCrgen Quittek wrote: >=20 > > Pyda, > >=20 > > Thanks for your comments. Please see replies to some of them inline. > >=20 > > --On 06.09.2003 14:15 Uhr -0700 Pyda Srisuresh = wrote: > >=20 > >> Below is text of the e-mail (a little revised) I sent to the authors= =20 > >> earlier. I > >> am including the text for wider audience. Below are my outstanding=20 > >> comments on > >> the draft. > >> > >> 1. For a NAT middlebox, I believe, the semantics ought to cover the=20 > >> following > >> transactions. My comments assume the following. > >> > >> A. NAT is configured on a per-interface basis. As such, the > >> Midcom/NAT transactions would be specified on a per-interfa= ce=20 > >> basis. > >=20 > >=20 > > I do not share this view. A midcom agent has the intention and capabi= lity > > to specify endpoints of communication across the middlebox. Which=20 > > interfaces > > of the middlebox are affected is not subject of midcom transactions. > >=20 > > The MIDCOM information model simplifies the network view by just sepa= rating > > an internal network and an external network. Whether or not the=20 > > middlebox has > > one or more interfaces connected to any of them is considered an=20 > > internal matter > > of the middlebox. > >=20 > > There is no statement in framework or requirements that oblige an age= nt=20 > > to find > > out which interfaces a middlebox is using. > >=20 > >> B. End-point below is to be refered as > >> for a PortBind. End-point for an address Bind will be > >> . The IP address can be V4 or V6. > >> C. The transactions specified below can be applicable to one o= r=20 > >> more > >> end-points. This will include address ranges, address > >> wild-carding, port ranges, and port wild-carding. > >> > >> > >> SetMapOwner [Full | Partial] [ >> Entry>] > >> - SetMapowner may be used by an agent to claim > >> ownership on a complete NAT map entry or a > >> portion of the entry. AgentId will be set as= the > >> owner of the entire map entry or portion the= reof. > >> > >> (CreateBind | CreatePortBind) > >> >> End-point> > >> - Agent specifies all the requisite Parameters= for > >> Bind(s) or PortBind(s). Agent requests middl= ebox > >> to create a BIND and respond back with an=20 > >> assigned > >> BindId. Middlebox to validate the authorizat= ion > >> prior to responding. > >> > >> (RequestCreateBind | RequestPortCreateBind) > >> [Oddity optio= n] > >> - Agent requests the Middlebox to create BIND(= s)=20 > >> for > >> the given End-point, optionally with an Oddi= ty > >> requirement. Middlebox to validate the > >> authorization, prior to assgining a BIND and > >> a BindId and returning the response. > >> > >> CreateOutboundSession > >> | > >> | >> Bindid> > >> > >> > >> - Agent specifies all the requisite Parameters= for > >> an outbound session. Agent requests middlebo= x > >> to create a session as specified and respond= back > >> with an assigned BindId. > >> The session may have one or two end-point > >> translations. The session may be derived dir= ectly > >> from the address map (or) from associated=20 > >> Bind-IDs. > >> Middlebox to validate the authorization prio= r to > >> responding. Note, the session tuple may have > >> wild-card elements. > >> > >> RequestCreateOutboundSession > >> | > >> | >> Bindid> > >> > >> - Agent requests the Middlebox to create an=20 > >> outbound > >> session for the given session tuple, using o= ne or > >> more map entries and/or end-point BINDs. Age= nt > >> to validate he authorization prior to respon= ding > >> back with a new session and session-id. As=20 > >> before, > >> the session tuple may have wild-card element= s. > >> > >> CreateInboundSession, > >> RequestCreateInboundSession > >> - Similar to the outbound counterparts. > >> > >> ModifyBindParameters > >> [] [MaximumIdletime>] [] > >> - These parameters may be specified either at = Bind > >> creation time or later. > >> > >> ModifySessionParameters > >> [] [MaximumIdletime>] [] > >> - These parameters may be specified either at=20 > >> session > >> creation time or later. Note, session here r= efers > >> to the NAT data sessions, not the Midcom age= nt > >> session. > >> > >> In particular, I would like to mention the notion of three resources > >> a NAT middlebox and midcom agent need to be cognizant of - > >> Address map entries, Binds and sessions. These resources may be a)=20 > >> created by > >> the agent, b) created by the NAT middlebox, or c) paramaters modifie= d=20 > >> by the > >> agent. > >=20 > >=20 > > The way I see it, MIDCOM does not distinguish binding and session (as= =20 > > the NAT MIB does). > > The point is that the MIDCOM protocol is not a middlebox management=20 > > protocol, but a > > protocol that allows applications to express requests for enabling=20 > > communication > > across a middlebox. > >=20 > >> 2. The notion of PRR is incomplete without the context of the entire= =20 > >> address > >> map entry. The reservation may not be specific to address/address-po= rt=20 > >> alone. > >> My view of this is simply that PRR is just another notion of ownersh= ip=20 > >> claim. > >> it just happens to be in relation to an address map entry. > >=20 > >=20 > > The intention behind PRR is just to reserve addresses at the middlebo= x. > > This can be doen without mapping them already. > >=20 > >> 3. When you combine the notion of PRR wth PER, the state transition=20 > >> diagram in > >> section 2.3.13 woudl be simplified, with the proviso that there woul= d=20 > >> be three > >> types of policy rules (address map entries, binds and sessions). > >=20 > >=20 > > Again, binds and sessions cannot be distinguished in the midcom world. > >=20 > >> 4. I agree with your notion of Session establishment and session=20 > >> termination > >> transactions. > >> > >> 5. I believe, the group Ids an agent would use during the lifetime o= f=20 > >> a Midcom > >> session should be specified by the agent - either at the midcom sess= ion > >> establishment time or afterwards whild the midcom session is alive.=20 > >> Given that > >> group-Ids are specific to an agent, it shoudl be agent's=20 > >> responsibility to > >> assign group IDs, not that of the middlebox's. Further, given that=20 > >> there are 3 > >=20 > >=20 > > Group IDs need to be unique per middlebox. > > This is hard to achieve if the agent assigns them. > >=20 > >> different types of resources (map entries, Binds and sessions), ther= e=20 > >> shoudl be > >> three different sets of group-Ids, one set for each resource type. > >> Middlebox will assign a default groupId of 0 to all entities that ar= e not > >> assigned a groupId by the agent. > >=20 > >=20 > > I prefer to have reservation rules and enable rules (bindings) to be > > able to share a group. because then the agent can extend or delete > > sets of them belonging together by just accessing a single group. > >=20 > > Cheers, > >=20 > > Juergen >=20 =3D=3D=3D=3D=3D _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Sun Sep 21 09:35:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26091 for ; Sun, 21 Sep 2003 09:35:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A14Mm-0007cg-Vr for midcom-archive@odin.ietf.org; Sun, 21 Sep 2003 09:35:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8LDZ8JT029296 for midcom-archive@odin.ietf.org; Sun, 21 Sep 2003 09:35:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A14Mg-0007bs-8S; Sun, 21 Sep 2003 09:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A14MZ-0007bX-5m for midcom@optimus.ietf.org; Sun, 21 Sep 2003 09:35:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26054 for ; Sun, 21 Sep 2003 09:34:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A14MN-0002jU-00 for midcom@ietf.org; Sun, 21 Sep 2003 09:34:43 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A14MC-0002iY-00 for midcom@ietf.org; Sun, 21 Sep 2003 09:34:32 -0400 Received: from zcard307.ca.nortel.com (americasm01.nt.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8LDXA127874; Sun, 21 Sep 2003 09:33:10 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZXHD3GF; Sun, 21 Sep 2003 09:33:10 -0400 Received: from nortelnetworks.com (acart1as.ca.nortel.com [47.129.129.2]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5M7Q0; Sun, 21 Sep 2003 09:33:10 -0400 Message-ID: <3F6DA88F.6000104@nortelnetworks.com> Date: Sun, 21 Sep 2003 09:33:03 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Pyda Srisuresh CC: =?ISO-8859-1?Q?J=FCrgen=5FQuittek?= , midcom@ietf.org, stiemerling@ccrle.nec.de Subject: Re: [midcom] Reminder: wg last call References: <20030920182150.12453.qmail@web40412.mail.yahoo.com> In-Reply-To: <20030920182150.12453.qmail@web40412.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit You have a couple of valid points in here that we have to address, but others that we need to discuss further. Before we start, let me recall the terminology we use in the semantics document. We speak of four addresses A0, A1, A2, and A3. They are illustrated in this diagram: +----------+ +----------+ | internal | A0 A1 +-----------+ A2 A3 | external | | endpoint +----------+ middlebox +----------+ endpoint | +----------+ +-----------+ +----------+ A0 and A3 are specified by the agent. A1 and A2 are assigned by the middlebox in response to PRR or PER. Pyda Srisuresh wrote: > --- Tom Taylor wrote: > [PTT - Generalities snipped] > > The abstract transaction model in the semantics draft has shortcomings. > a) PRR/PER will only work in simplest of configurations. > b) The transaction model, as specified, imposes rather unnecessarily complex > and yet times, impossible task on the middlebox. > > Let us consider the "PRR" transaction (section 2.3.7). PRR is supposed to > reserve an address or a port number range. This might work in the case the > middlebox has just one map entry in the address map (say 0.0.0.0/0 -> X1 or > 0.0.0.0/0 -> X2/n). This will fail the moment the address map has multiple map > entries. Further, an address or port-range reservation is meaningful only in > the context of an address map entry. Say, you had 3 address map entries as > follows. > 10.1.0.0/16 -> X1/24; > 10.2.5.0/24 -> X2/28; > 0.0.0.0/0 -> X3; > > Say, PRR made a request for an address without the context of a map entry. Say, > the middlebox responded back with an address in X1 range. This address would be > meaningless to the agent, if the agent happens to be using an address outside > the range of 10.1.0.0/16. So, the PRR request ought to specify the address map > entry from which the request is beign made. [PTT] Looks like we should include address A0 (the inside endpoint address) as a parameter of the PRR. That gives the middlebox the information it needs to select the right map entry. It's still unnecessary for the agent to know the map entries themselves. > > Even if the agent was using an address in the range of 10.1.0.0/16 - say, > 10.1.0.1, and the agent obtains an address, say X1.1, the middlebox has no way > to know that all sessions from 10.1.0.1 have to be bound to X1.1. The agent > might create a BIND (using PER) at a later time. But, prior to this, if NAT > sees any session originating from 10.1.0.1, it would bind the address to one of > the available addresses within X1/8 (different from X1.1, as X1.1 is reseved by > an agent). Now, lots of chaos ensues because, the PER from the agent would > fail. > [PTT] This one is definitely a concern. It seems to me we have to specify in the semantics of PRR that if a reservation is made, it must be honoured in subsequent sessions set up automatically by the middlebox (need better words). In the context of your particular example, if the middlebox assigns address X1.1 (as address A2) to 10.1.0.1 (address A0) as a result of PRR, then while the reservation holds, any subsequent BINDs for sessions from 10.1.0.1 must use address X1.1. [PTT - implementation details snipped] > > Now, let us consider the case of PER transaction(section 2.3.8). PER in the > context of a NAT refers to the agent creating a NAT binding with specific > parameters. This will fail if the prameters specified in the bind-create > request donot correspond to one or more (in the case of twice-NAT) address map > entries. Without reference of an address map entry, the agent has no knowledge > of whether to request for an address bind or a port bind. Further, the binding > is meaningless without the exact session description to a symmetric NAPT. This > is because symmetric NAPT uses different port bindings for the same (private IP > address, port) tuple used in different sessions. The port bind may work only > for the first session that originates from (provate IP address, port). There > are other caveats. Without a PRR preceding the PER, how is the PER to know what > external address to bound to? Why not let the middlebox select the external > address to bound to? > > This is why I suggested the tansactions CreateBind, CreateportBind, > RequestCreateBind, and RequestCreatePortBind to create binds unequivocally. > These transactions use address map as an argument. Either the agent or the > middlebox can create a bind. [PTT] You are arguing that if the agent knows the map entries, it can request the specific binding that it needs. I'll put it the other way: the current PER parameters include the internal endpoint address A0, the external endpoint address A3, and, if a PRR was performed previously, a reference to the A1 and A2 assignments that resulted from that PRR. What other information does the middlebox need to complete the bind? > > Creating binds is not adequate. The agent needs to be able to specify the > permitted sessions as well. Without going into the details, i will simply > suggest FTP(TCP based) and TFTP(UDP based) are examples of this. > [PTT] I want to carry on further discussion of this point with a clear understanding of your terminology. Please indicate what additional parameters distinguish a session from a bind. [PTT - remainder snipped] _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Sep 22 16:56:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10441 for ; Mon, 22 Sep 2003 16:56:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Xj2-0004dJ-Fi for midcom-archive@odin.ietf.org; Mon, 22 Sep 2003 16:56:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MKu4HB017805 for midcom-archive@odin.ietf.org; Mon, 22 Sep 2003 16:56:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Xiz-0004cc-V3; Mon, 22 Sep 2003 16:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Xig-0004a0-SY for midcom@optimus.ietf.org; Mon, 22 Sep 2003 16:55:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10381 for ; Mon, 22 Sep 2003 16:55:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1Xie-0000R5-00 for midcom@ietf.org; Mon, 22 Sep 2003 16:55:40 -0400 Received: from web40414.mail.yahoo.com ([66.218.78.111]) by ietf-mx with smtp (Exim 4.12) id 1A1Xie-0000O9-00 for midcom@ietf.org; Mon, 22 Sep 2003 16:55:40 -0400 Message-ID: <20030922205509.2542.qmail@web40414.mail.yahoo.com> Received: from [66.224.113.194] by web40414.mail.yahoo.com via HTTP; Mon, 22 Sep 2003 13:55:09 PDT Date: Mon, 22 Sep 2003 13:55:09 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Reminder: wg last call To: Tom Taylor Cc: "Jürgen_Quittek" , midcom@ietf.org, stiemerling@ccrle.nec.de In-Reply-To: <3F6DA88F.6000104@nortelnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --- Tom Taylor wrote: > You have a couple of valid points in here that we have to address, but others > that > we need to discuss further. Before we start, let me recall the terminology > we use > in the semantics document. We speak of four addresses A0, A1, A2, and A3. > They are > illustrated in this diagram: > > +----------+ +----------+ > | internal | A0 A1 +-----------+ A2 A3 | external | > | endpoint +----------+ middlebox +----------+ endpoint | > +----------+ +-----------+ +----------+ > > A0 and A3 are specified by the agent. A1 and A2 are assigned by the > middlebox in > response to PRR or PER. > Assuming the agent is on A0, how does the agent know the session is between A0 and A3? A0 only knows that the session is to A1. Middlebox does the needed translation from A1 to A3. Also, I would like to point out that the agent need not be the end-host itself. It could be a proxy in the middle, representing several end-hosts. > Pyda Srisuresh wrote: > > --- Tom Taylor wrote: > > > [PTT - Generalities snipped] > > > > The abstract transaction model in the semantics draft has shortcomings. > > a) PRR/PER will only work in simplest of configurations. > > b) The transaction model, as specified, imposes rather unnecessarily > complex > > and yet times, impossible task on the middlebox. > > > > Let us consider the "PRR" transaction (section 2.3.7). PRR is supposed to > > reserve an address or a port number range. This might work in the case the > > middlebox has just one map entry in the address map (say 0.0.0.0/0 -> X1 or > > 0.0.0.0/0 -> X2/n). This will fail the moment the address map has multiple > map > > entries. Further, an address or port-range reservation is meaningful only > in > > the context of an address map entry. Say, you had 3 address map entries as > > follows. > > 10.1.0.0/16 -> X1/24; > > 10.2.5.0/24 -> X2/28; > > 0.0.0.0/0 -> X3; > > > > Say, PRR made a request for an address without the context of a map entry. > Say, > > the middlebox responded back with an address in X1 range. This address > would be > > meaningless to the agent, if the agent happens to be using an address > outside > > the range of 10.1.0.0/16. So, the PRR request ought to specify the address > map > > entry from which the request is beign made. > > [PTT] Looks like we should include address A0 (the inside endpoint address) > as a > parameter of the PRR. That gives the middlebox the information it needs to > select > the right map entry. It's still unnecessary for the agent to know the map > entries > themselves. That would make sense in the case the agent is representing just one host. Otherwise, the agent needs to specify the address range the agent represents. > > > > > Even if the agent was using an address in the range of 10.1.0.0/16 - say, > > 10.1.0.1, and the agent obtains an address, say X1.1, the middlebox has no > way > > to know that all sessions from 10.1.0.1 have to be bound to X1.1. The agent > > might create a BIND (using PER) at a later time. But, prior to this, if NAT > > sees any session originating from 10.1.0.1, it would bind the address to > one of > > the available addresses within X1/8 (different from X1.1, as X1.1 is > reseved by > > an agent). Now, lots of chaos ensues because, the PER from the agent would > > fail. > > > > [PTT] This one is definitely a concern. It seems to me we have to specify in > the > semantics of PRR that if a reservation is made, it must be honoured in > subsequent > sessions set up automatically by the middlebox (need better words). In the > context > of your particular example, if the middlebox assigns address X1.1 (as address > A2) to > 10.1.0.1 (address A0) as a result of PRR, then while the reservation holds, > any > subsequent BINDs for sessions from 10.1.0.1 must use address X1.1. > How is this different from the partial/full address map entry ownership I mentioned? > [PTT - implementation details snipped] > > > > Now, let us consider the case of PER transaction(section 2.3.8). PER in the > > context of a NAT refers to the agent creating a NAT binding with specific > > parameters. This will fail if the prameters specified in the bind-create > > request donot correspond to one or more (in the case of twice-NAT) address > map > > entries. Without reference of an address map entry, the agent has no > knowledge > > of whether to request for an address bind or a port bind. Further, the > binding > > is meaningless without the exact session description to a symmetric NAPT. > This > > is because symmetric NAPT uses different port bindings for the same > (private IP > > address, port) tuple used in different sessions. The port bind may work > only > > for the first session that originates from (provate IP address, port). > There > > are other caveats. Without a PRR preceding the PER, how is the PER to know > what > > external address to bound to? Why not let the middlebox select the external > > address to bound to? > > > > This is why I suggested the tansactions CreateBind, CreateportBind, > > RequestCreateBind, and RequestCreatePortBind to create binds unequivocally. > > These transactions use address map as an argument. Either the agent or the > > middlebox can create a bind. > > [PTT] You are arguing that if the agent knows the map entries, it can request > the > specific binding that it needs. I'll put it the other way: the current PER > parameters include the internal endpoint address A0, the external endpoint > address > A3, and, if a PRR was performed previously, a reference to the A1 and A2 > assignments > that resulted from that PRR. What other information does the middlebox need > to > complete the bind? Couple of questions: a) How did the agent know that the session is from A0 to A3? b) Assuming it knew the above somehow, you are saying that PRR should return back a single handle to the agent. Now, is this going to be a handle for a reserved session, not a BIND? There is a big difference between a bind and a session. Depending upon what the middlebox returns, the agent has different work to do. For example, if the agent knows a BIND is setup in a middlebox, it doesnot need to make a request for every single session it needs to setup using this bind. The middlebox does this automatically. > > > > > Creating binds is not adequate. The agent needs to be able to specify the > > permitted sessions as well. Without going into the details, i will simply > > suggest FTP(TCP based) and TFTP(UDP based) are examples of this. > > > [PTT] I want to carry on further discussion of this point with a clear > understanding > of your terminology. Please indicate what additional parameters distinguish > a > session from a bind. A Bind refers to half-session & its transaltion parameters. In the case of address bind, only the address is translated; port does not get translated. In the case of port bind, both address and port of the half session are translated. > > [PTT - remainder snipped] > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom cheers, suresh ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Sep 22 18:13:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14497 for ; Mon, 22 Sep 2003 18:13:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1YvY-0005Je-P1 for midcom-archive@odin.ietf.org; Mon, 22 Sep 2003 18:13:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MMD4Jn020430 for midcom-archive@odin.ietf.org; Mon, 22 Sep 2003 18:13:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1YvV-0005Ij-AX; Mon, 22 Sep 2003 18:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1YuW-0005Dq-1e for midcom@optimus.ietf.org; Mon, 22 Sep 2003 18:12:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14331 for ; Mon, 22 Sep 2003 18:11:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1YuT-0006lo-00 for midcom@ietf.org; Mon, 22 Sep 2003 18:11:57 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A1YuS-0006jC-00 for midcom@ietf.org; Mon, 22 Sep 2003 18:11:56 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8MMBBX01072; Mon, 22 Sep 2003 18:11:11 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZX2V682; Mon, 22 Sep 2003 18:11:11 -0400 Received: from nortelnetworks.com (acart1as.ca.nortel.com [47.129.129.2]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5M790; Mon, 22 Sep 2003 18:11:11 -0400 Message-ID: <3F6F737E.6040306@nortelnetworks.com> Date: Mon, 22 Sep 2003 18:11:10 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Pyda Srisuresh CC: =?ISO-8859-1?Q?J=FCrgen=5FQuittek?= , midcom@ietf.org, stiemerling@ccrle.nec.de Subject: Re: [midcom] Reminder: wg last call References: <20030922205509.2542.qmail@web40414.mail.yahoo.com> In-Reply-To: <20030922205509.2542.qmail@web40414.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit You're under a misconception. Address A0 is the internal address of the host whose application is being enabled, not of the agent. And A3 is known (or sometimes not known, hence the need for wildcarding) from the application protocol as sent by the endpoint via the agent. This takes care of your first two comments, I think. More on bind vs. session near the bottom. Pyda Srisuresh wrote: > --- Tom Taylor wrote: > >>You have a couple of valid points in here that we have to address, but others >>that >>we need to discuss further. Before we start, let me recall the terminology >>we use >>in the semantics document. We speak of four addresses A0, A1, A2, and A3. >>They are >>illustrated in this diagram: >> >> +----------+ +----------+ >> | internal | A0 A1 +-----------+ A2 A3 | external | >> | endpoint +----------+ middlebox +----------+ endpoint | >> +----------+ +-----------+ +----------+ >> >>A0 and A3 are specified by the agent. A1 and A2 are assigned by the >>middlebox in >>response to PRR or PER. >> > > > Assuming the agent is on A0, how does the agent know the session is between A0 > and A3? A0 only knows that the session is to A1. Middlebox does the needed > translation from A1 to A3. > > Also, I would like to point out that the agent need not be the end-host itself. > It could be a proxy in the middle, representing several end-hosts. > > > >>Pyda Srisuresh wrote: >> >>>--- Tom Taylor wrote: >>> >> >>[PTT - Generalities snipped] >> >>>The abstract transaction model in the semantics draft has shortcomings. >>>a) PRR/PER will only work in simplest of configurations. >>>b) The transaction model, as specified, imposes rather unnecessarily >> >>complex >> >>>and yet times, impossible task on the middlebox. >>> >>>Let us consider the "PRR" transaction (section 2.3.7). PRR is supposed to >>>reserve an address or a port number range. This might work in the case the >>>middlebox has just one map entry in the address map (say 0.0.0.0/0 -> X1 or >>>0.0.0.0/0 -> X2/n). This will fail the moment the address map has multiple >> >>map >> >>>entries. Further, an address or port-range reservation is meaningful only >> >>in >> >>>the context of an address map entry. Say, you had 3 address map entries as >>>follows. >>> 10.1.0.0/16 -> X1/24; >>> 10.2.5.0/24 -> X2/28; >>> 0.0.0.0/0 -> X3; >>> >>>Say, PRR made a request for an address without the context of a map entry. >> >>Say, >> >>>the middlebox responded back with an address in X1 range. This address >> >>would be >> >>>meaningless to the agent, if the agent happens to be using an address >> >>outside >> >>>the range of 10.1.0.0/16. So, the PRR request ought to specify the address >> >>map >> >>>entry from which the request is beign made. >> >>[PTT] Looks like we should include address A0 (the inside endpoint address) >>as a >>parameter of the PRR. That gives the middlebox the information it needs to >>select >>the right map entry. It's still unnecessary for the agent to know the map >>entries >>themselves. > > > That would make sense in the case the agent is representing just one host. > Otherwise, the agent needs to specify the address range the agent represents. > > >>>Even if the agent was using an address in the range of 10.1.0.0/16 - say, >>>10.1.0.1, and the agent obtains an address, say X1.1, the middlebox has no >> >>way >> >>>to know that all sessions from 10.1.0.1 have to be bound to X1.1. The agent >>>might create a BIND (using PER) at a later time. But, prior to this, if NAT >>>sees any session originating from 10.1.0.1, it would bind the address to >> >>one of >> >>>the available addresses within X1/8 (different from X1.1, as X1.1 is >> >>reseved by >> >>>an agent). Now, lots of chaos ensues because, the PER from the agent would >>>fail. >>> >> >>[PTT] This one is definitely a concern. It seems to me we have to specify in >>the >>semantics of PRR that if a reservation is made, it must be honoured in >>subsequent >>sessions set up automatically by the middlebox (need better words). In the >>context >>of your particular example, if the middlebox assigns address X1.1 (as address >>A2) to >>10.1.0.1 (address A0) as a result of PRR, then while the reservation holds, >>any >>subsequent BINDs for sessions from 10.1.0.1 must use address X1.1. >> > > > How is this different from the partial/full address map entry ownership I > mentioned? > > >>[PTT - implementation details snipped] >> >>>Now, let us consider the case of PER transaction(section 2.3.8). PER in the >>>context of a NAT refers to the agent creating a NAT binding with specific >>>parameters. This will fail if the prameters specified in the bind-create >>>request donot correspond to one or more (in the case of twice-NAT) address >> >>map >> >>>entries. Without reference of an address map entry, the agent has no >> >>knowledge >> >>>of whether to request for an address bind or a port bind. Further, the >> >>binding >> >>>is meaningless without the exact session description to a symmetric NAPT. >> >>This >> >>>is because symmetric NAPT uses different port bindings for the same >> >>(private IP >> >>>address, port) tuple used in different sessions. The port bind may work >> >>only >> >>>for the first session that originates from (provate IP address, port). >> >>There >> >>>are other caveats. Without a PRR preceding the PER, how is the PER to know >> >>what >> >>>external address to bound to? Why not let the middlebox select the external >>>address to bound to? >>> >>>This is why I suggested the tansactions CreateBind, CreateportBind, >>>RequestCreateBind, and RequestCreatePortBind to create binds unequivocally. >>>These transactions use address map as an argument. Either the agent or the >>>middlebox can create a bind. >> >>[PTT] You are arguing that if the agent knows the map entries, it can request >>the >>specific binding that it needs. I'll put it the other way: the current PER >>parameters include the internal endpoint address A0, the external endpoint >>address >>A3, and, if a PRR was performed previously, a reference to the A1 and A2 >>assignments >>that resulted from that PRR. What other information does the middlebox need >>to >>complete the bind? > > > Couple of questions: > a) How did the agent know that the session is from A0 to A3? [PTT] As noted at the start of this note: from the application protocol sent by the interior end point. > > b) Assuming it knew the above somehow, you are saying that PRR should return > back a single handle to the agent. Now, is this going to be a handle for a > reserved session, not a BIND? There is a big difference between a bind and a > session. Depending upon what the middlebox returns, the agent has different > work to do. For example, if the agent knows a BIND is setup in a middlebox, it > doesnot need to make a request for every single session it needs to setup using > this bind. The middlebox does this automatically. > [PTT] Please see below. > >>>Creating binds is not adequate. The agent needs to be able to specify the >>>permitted sessions as well. Without going into the details, i will simply >>>suggest FTP(TCP based) and TFTP(UDP based) are examples of this. >>> >> >>[PTT] I want to carry on further discussion of this point with a clear >>understanding >>of your terminology. Please indicate what additional parameters distinguish >>a >>session from a bind. > > > A Bind refers to half-session & its transaltion parameters. In the case of > address bind, only the address is translated; port does not get translated. In > the case of port bind, both address and port of the half session are > translated. > [PTT] I think you are saying that a session is two binds, one in each direction. Aside from that, there are no additional parameters. It does seem that our "policy rules" correspond to binds. In addition, we don't have the concept of session (if I understand you correctly) because we request policy rules for the two directions independently. In fact, I'm not sure the idea of a bidirectional session makes much sense -- the individual packet flows (e.g. outgoing signalling, incoming signalling, outgoing media1, incoming media1, etc.) are activated at different points in time. It seems likely that our "group" is the closest thing to a session. As far as the difference between address bind and port bind, I think we express that by specifying whether we are asking for IP (no ports) or UDP/TCP (ports specified). ... _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Tue Sep 23 10:14:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15230 for ; Tue, 23 Sep 2003 10:14:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nvc-0006Nu-De for midcom-archive@odin.ietf.org; Tue, 23 Sep 2003 10:14:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NEE8qv024517 for midcom-archive@odin.ietf.org; Tue, 23 Sep 2003 10:14:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nvV-0006Mx-6W; Tue, 23 Sep 2003 10:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1nv8-0006MY-63 for midcom@optimus.ietf.org; Tue, 23 Sep 2003 10:13:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15096 for ; Tue, 23 Sep 2003 10:13:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1nv5-0000MQ-00 for midcom@ietf.org; Tue, 23 Sep 2003 10:13:35 -0400 Received: from web40403.mail.yahoo.com ([66.218.78.100]) by ietf-mx with smtp (Exim 4.12) id 1A1nv5-0000M0-00 for midcom@ietf.org; Tue, 23 Sep 2003 10:13:35 -0400 Message-ID: <20030923141304.82577.qmail@web40403.mail.yahoo.com> Received: from [67.164.29.130] by web40403.mail.yahoo.com via HTTP; Tue, 23 Sep 2003 07:13:04 PDT Date: Tue, 23 Sep 2003 07:13:04 -0700 (PDT) From: Pyda Srisuresh Subject: Midcom semantics transaction model (was Re: [midcom] Reminder: wg last call) To: Tom Taylor Cc: "Jürgen_Quittek" , midcom@ietf.org, stiemerling@ccrle.nec.de In-Reply-To: <3F6F737E.6040306@nortelnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Tom/Jurgen I've changed the subject line. Please my comments inline. Thanks. --- Tom Taylor wrote: > You're under a misconception. Address A0 is the internal address of the host > whose > application is being enabled, not of the agent. I did assume A0 to be the address of the host. The agent had to be somewhere along the line of communication. Since you were refering to an agent representing just this host, I assumed the agent is also on A0. Now that you bring this up, does it matter where the agent is located? The agent had to be on A0, A1 or in-between as on a proxy, right? I dodnt think it mattered, except when you start assuming the agent is representing just one host. > And A3 is known (or > sometimes not > known, hence the need for wildcarding) from the application protocol as sent > by the > endpoint via the agent. OK. I guess you are using the traditional-NAT model, not twice-NAT. The diagram implied twice-NAT and I assuemd that. > This takes care of your first two comments, I > think. > More on bind vs. session near the bottom. > As for bind vs. session, you did not interpret what I said correctly. sounds like, there is some confusion. I suggest you lookup RFC 2663 or 3022 for what a binding is. <... Rest of the e-mail snipped> regards, suresh ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Sep 24 08:43:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11296 for ; Wed, 24 Sep 2003 08:43:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28z4-00082y-85 for midcom-archive@odin.ietf.org; Wed, 24 Sep 2003 08:43:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OCh6pF030928 for midcom-archive@odin.ietf.org; Wed, 24 Sep 2003 08:43:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28yz-000821-JC; Wed, 24 Sep 2003 08:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28yu-00081I-FM for midcom@optimus.ietf.org; Wed, 24 Sep 2003 08:42:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11250 for ; Wed, 24 Sep 2003 08:42:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A28yt-0003L3-00 for midcom@ietf.org; Wed, 24 Sep 2003 08:42:55 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1A28ys-0003Kb-00 for midcom@ietf.org; Wed, 24 Sep 2003 08:42:54 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8OCg3W28529; Wed, 24 Sep 2003 08:42:03 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZX2WVAP; Wed, 24 Sep 2003 08:42:03 -0400 Received: from nortelnetworks.com (acart1dv.ca.nortel.com [47.129.129.104]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5M8RB; Wed, 24 Sep 2003 08:42:03 -0400 Message-ID: <3F719116.90709@nortelnetworks.com> Date: Wed, 24 Sep 2003 08:41:58 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Pyda Srisuresh CC: =?ISO-8859-1?Q?J=FCrgen=5FQuittek?= , midcom@ietf.org, stiemerling@ccrle.nec.de Subject: Re: Midcom semantics transaction model (was Re: [midcom] Reminder: wg last call) References: <20030923141304.82577.qmail@web40403.mail.yahoo.com> In-Reply-To: <20030923141304.82577.qmail@web40403.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Comments in line. Pyda Srisuresh wrote: > Tom/Jurgen > > I've changed the subject line. Please my comments inline. Thanks. > > --- Tom Taylor wrote: > >>You're under a misconception. Address A0 is the internal address of the host >>whose >>application is being enabled, not of the agent. > > > I did assume A0 to be the address of the host. The agent had to be somewhere > along the line of communication. Since you were refering to an agent > representing just this host, I assumed the agent is also on A0. Now that you > bring this up, does it matter where the agent is located? The agent had to be > on A0, A1 or in-between as on a proxy, right? I dodnt think it mattered, except > when you start assuming the agent is representing just one host. [PTT] A PRR or PER is issued on behalf of a single host. However, an agent may issue these requests on behalf of multiple hosts during a single MIDCOM session. Regardless, agreed that the only constraint on agent location is that it be on the application signalling path. > > >> And A3 is known (or >>sometimes not >>known, hence the need for wildcarding) from the application protocol as sent >>by the >> endpoint via the agent. > > > OK. I guess you are using the traditional-NAT model, not twice-NAT. The diagram > implied twice-NAT and I assuemd that. > [PTT] We are using either model. You seem to be assuming that the only way the application can know A3 is from the incoming IP header. In fact, we assume it is known by any means except that. Most typically the external address would be carried in the application protocol content (e.g. SDP) inside the packet. > >> This takes care of your first two comments, I >>think. >>More on bind vs. session near the bottom. >> > > As for bind vs. session, you did not interpret what I said correctly. sounds > like, there is some confusion. I suggest you lookup RFC 2663 or 3022 for what a > binding is. > [PTT] OK, looking at RFC 2663, I feel quite clear on what a session is. It seems to imply application-level understanding on the part of the middlebox. The whole point of MIDCOM is to restrict the application-level understanding to the agent and the endpoint hosts. Thus the transactions between the agent and the middlebox are concerned with packet flows rather than session flows. The MIDCOM "session" is a whole other matter. It is simply a working relationship established between an agent and a middlebox. The packet flows enabled during the MIDCOM session may or may not be related to each other. > <... Rest of the e-mail snipped> > > regards, > suresh > > ===== > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Wed Sep 24 10:41:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18579 for ; Wed, 24 Sep 2003 10:41:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ApK-0007s6-E8 for midcom-archive@odin.ietf.org; Wed, 24 Sep 2003 10:41:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OEfA6G030254 for midcom-archive@odin.ietf.org; Wed, 24 Sep 2003 10:41:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ApC-0007rX-9e; Wed, 24 Sep 2003 10:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2AoW-0007qq-F2 for midcom@optimus.ietf.org; Wed, 24 Sep 2003 10:40:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18482 for ; Wed, 24 Sep 2003 10:40:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2AoU-0004zX-00 for midcom@ietf.org; Wed, 24 Sep 2003 10:40:18 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A2AoT-0004yn-00 for midcom@ietf.org; Wed, 24 Sep 2003 10:40:17 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.9) with ESMTP id h8OEdjHJ028171; Wed, 24 Sep 2003 16:39:46 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 8EDDFC4F0B; Wed, 24 Sep 2003 16:09:45 +0200 (CEST) Date: Wed, 24 Sep 2003 16:39:28 +0200 From: Martin Stiemerling To: Pyda Srisuresh , Tom Taylor , JXrgen_Quittek Cc: midcom@ietf.org Subject: Re: [midcom] Reminder: wg last call/ Mapping ranges and PRR Message-ID: <3164500.1064421568@[10.1.1.109]> In-Reply-To: <20030920182150.12453.qmail@web40412.mail.yahoo.com> References: <20030920182150.12453.qmail@web40412.mail.yahoo.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Pyda, I am splitting your email in several in order to reflect the different issues to be handled. Martin --On Samstag, 20. September 2003 11:21 -0700 Pyda Srisuresh wrote: [...] |> The second point is partly independent of this: my preference as a |> "semantics" |> author to take an abstract view of firewall and NAT operation, with the |> aim of |> avoiding as much as possible the need to know what services the middlebox |> supports, |> is in definite contrast to the content of the current NAT and firewall |> MIBs. | | Please see my note above. | | The abstract transaction model in the semantics draft has shortcomings. | a) PRR/PER will only work in simplest of configurations. | b) The transaction model, as specified, imposes rather unnecessarily | complex and yet times, impossible task on the middlebox. | | Let us consider the "PRR" transaction (section 2.3.7). PRR is supposed to | reserve an address or a port number range. This might work in the case the | middlebox has just one map entry in the address map (say 0.0.0.0/0 -> X1 | or 0.0.0.0/0 -> X2/n). This will fail the moment the address map has | multiple map entries. Further, an address or port-range reservation is | meaningful only in the context of an address map entry. Say, you had 3 | address map entries as follows. | 10.1.0.0/16 -> X1/24; | 10.2.5.0/24 -> X2/28; | 0.0.0.0/0 -> X3; | | Say, PRR made a request for an address without the context of a map | entry. Say, the middlebox responded back with an address in X1 range. | This address would be meaningless to the agent, if the agent happens to | be using an address outside the range of 10.1.0.0/16. So, the PRR request | ought to specify the address map entry from which the request is beign | made. | | Even if the agent was using an address in the range of 10.1.0.0/16 - say, | 10.1.0.1, and the agent obtains an address, say X1.1, the middlebox has | no way to know that all sessions from 10.1.0.1 have to be bound to X1.1. | The agent might create a BIND (using PER) at a later time. But, prior to | this, if NAT sees any session originating from 10.1.0.1, it would bind | the address to one of the available addresses within X1/8 (different from | X1.1, as X1.1 is reseved by an agent). Now, lots of chaos ensues because, | the PER from the agent would fail. | | This is why I suggested the tansaction "SetMapOwner | [Full | Partial] []" to claim full/partial ownership | of an address map entry unequivocally. This is fully contextual and there | are no race conditions between the agent and the middlebox. Ok, in this point I do agree with Tom's proposal to add A0 to the PRR transactions, so the middlebox can find out from where the request is coming and which address range to choose. As long as nobody else from the mailing list has any objections to that, we will put this is the next revision of the semantics. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Sep 25 10:05:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25556 for ; Thu, 25 Sep 2003 10:05:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Wk9-00021Y-IR for midcom-archive@odin.ietf.org; Thu, 25 Sep 2003 10:05:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PE5Hib007774 for midcom-archive@odin.ietf.org; Thu, 25 Sep 2003 10:05:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Wju-00020j-Lm; Thu, 25 Sep 2003 10:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2WjN-0001zp-Bm for midcom@optimus.ietf.org; Thu, 25 Sep 2003 10:04:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25360 for ; Thu, 25 Sep 2003 10:04:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2WjL-0006Vt-00 for midcom@ietf.org; Thu, 25 Sep 2003 10:04:27 -0400 Received: from web40405.mail.yahoo.com ([66.218.78.102]) by ietf-mx with smtp (Exim 4.12) id 1A2WjK-0006Us-00 for midcom@ietf.org; Thu, 25 Sep 2003 10:04:26 -0400 Message-ID: <20030925140354.76240.qmail@web40405.mail.yahoo.com> Received: from [67.164.29.130] by web40405.mail.yahoo.com via HTTP; Thu, 25 Sep 2003 07:03:54 PDT Date: Thu, 25 Sep 2003 07:03:54 -0700 (PDT) From: Pyda Srisuresh To: midcom@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [midcom] WG feedback solicited - Midcom semantics Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Folks, The authors and I are unable to make much progress due to a basic conflict in our perception of the Midcom objective and how to go about it. The authors and I discussed over the phone yesterday and decided that we post you this e-mail so you can provide the feedback. Your feedback will be valuable in order to make progress. Thank you. 1. I believe, the objective of the Midcom protocol (and hence the semantics) is to keep the middleboxes simple, without requiring ALGs. Agents will control middlebox resources (via midcom) to allow the end-2-end applications to work. As such, the middleboxes should permit their resources to be controlled by agents via the midcom protocol. The authors believe (Correct me if I am wrong) that the objective of the semantics is to require the agents to be as simple as possible in their interactions with middlebox. The complexity should be moved to the middlebox. 2. I believe, in order for the agents to control middlebox resources, the agents ought to have the knowledge of the middlebox configuration. - Relevent interface, NAT address map entries, default MaxIdleTimeouts configured. - Relevant interface specific firewall filters configured. The authors believe (correct me, if I am wrong), the agent should not have to know the middlebox configuration in order to run midcom protocol. 3. Lastly, I believe, the midcom protocol should allow agents to control all middlebox resources and parameters. Midcom protocol should be aware of the middlebox resources and be designed to execute on these resources. Specifically, the resource for a NAT middlebox are: NAT address map entries, address/port bindings, and sessions. NAT controllable parameters are: MaxIdleTimeouts for bindings and sessions. The resources for a firewall are: permit/deny packet filters. Further to these native parameters, Midcom requires the middleboxes to support a) resource Lifetimes, b) resource Grouping and b) asynchronous notification for the resources the agents control. A middlebox should incorporate these into its resources to support midcom. The authors create an abstract model of resources for midcom protocol and mandate middleboxes to meet that abstract resource model. In the semantics model, the authors argue, there ought to be a one-to-one relationship between bindings and sessions and that the middlebox should figure out how to make this happen. The authors donot care to know if a session had 2 bindings, 1 binding or had no binding. Well, thats all for now. Thank you. regards, suresh ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Sep 25 10:14:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26635 for ; Thu, 25 Sep 2003 10:14:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Wsc-0002i4-K5 for midcom-archive@odin.ietf.org; Thu, 25 Sep 2003 10:14:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PEE215010391 for midcom-archive@odin.ietf.org; Thu, 25 Sep 2003 10:14:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Wsa-0002h4-Hp; Thu, 25 Sep 2003 10:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Wrl-0002eO-RZ for midcom@optimus.ietf.org; Thu, 25 Sep 2003 10:13:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26461 for ; Thu, 25 Sep 2003 10:13:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2WrX-0006cq-00 for midcom@ietf.org; Thu, 25 Sep 2003 10:12:55 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A2WrW-0006cl-00 for midcom@ietf.org; Thu, 25 Sep 2003 10:12:55 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8PECM0E027696; Thu, 25 Sep 2003 07:12:23 -0700 (PDT) Received: from cisco.com (sjc-vpn4-123.cisco.com [10.21.80.123]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMM97666; Thu, 25 Sep 2003 07:12:19 -0700 (PDT) Date: Thu, 25 Sep 2003 10:12:18 -0400 Subject: Re: [midcom] WG feedback solicited - Midcom semantics Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: midcom@ietf.org To: Pyda Srisuresh From: Melinda Shore In-Reply-To: <20030925140354.76240.qmail@web40405.mail.yahoo.com> Message-Id: <45A06638-EF62-11D7-A8F5-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thursday, September 25, 2003, at 10:03 AM, Pyda Srisuresh wrote: > 3. Lastly, I believe, the midcom protocol should allow agents to > control all > middlebox resources and parameters. Thanks for the note. Your query relates to two decisions that were made by the working group some time ago: 1) network topology is out-of-scope, and 2) midcom is not to be a general-purpose management mechanism, but is intended only to support traversal of these devices through resource requests. There was never any intention to support device configuration and interface management, and those functions are out-of- scope for the working group. The last time this was proposed (by me) it met decidedly, uh, enthusiastic disagreement from the working group. We're not going to be revisiting either decision at this very late date. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Thu Sep 25 12:43:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04577 for ; Thu, 25 Sep 2003 12:43:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZCo-00050l-V6 for midcom-archive@odin.ietf.org; Thu, 25 Sep 2003 12:43:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PGh2k8019254 for midcom-archive@odin.ietf.org; Thu, 25 Sep 2003 12:43:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZCm-000507-KJ; Thu, 25 Sep 2003 12:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZCT-0004zn-8b for midcom@optimus.ietf.org; Thu, 25 Sep 2003 12:42:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04430 for ; Thu, 25 Sep 2003 12:42:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2ZCR-00019m-00 for midcom@ietf.org; Thu, 25 Sep 2003 12:42:39 -0400 Received: from web40405.mail.yahoo.com ([66.218.78.102]) by ietf-mx with smtp (Exim 4.12) id 1A2ZCQ-00016s-00 for midcom@ietf.org; Thu, 25 Sep 2003 12:42:38 -0400 Message-ID: <20030925164207.12832.qmail@web40405.mail.yahoo.com> Received: from [66.224.113.194] by web40405.mail.yahoo.com via HTTP; Thu, 25 Sep 2003 09:42:07 PDT Date: Thu, 25 Sep 2003 09:42:07 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] WG feedback solicited - Midcom semantics To: Melinda Shore Cc: midcom@ietf.org In-Reply-To: <45A06638-EF62-11D7-A8F5-000A95E35274@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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --- Melinda Shore wrote: > On Thursday, September 25, 2003, at 10:03 AM, Pyda Srisuresh wrote: > > 3. Lastly, I believe, the midcom protocol should allow agents to > > control all > > middlebox resources and parameters. > > Thanks for the note. No problem. > Your query relates to two decisions > that were made by the working group some time ago: 1) network > topology is out-of-scope, OK. Why do you believe, I was suggestign this? Just to be clear, I was not suggesting this. > and 2) midcom is not to be a > general-purpose management mechanism, but is intended only to > support traversal of these devices through resource requests. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I assume, you meant traversal of applications through the middlebox devices. Once again, Just to be clear, I neither implied nor intended the Midcom to be a general-purpose management protocol. The very first note I made was that Midcom objective was to move ALGs out of middleboxes. So, all the instrumentation that is necessary to move the ALGs out of middlebox was all I was refering to. > There was never any intention to support device configuration > and interface management, and those functions are out-of- > scope for the working group. Most certainly. Device configuration and management is the function of middleboxes. I.e., NAT and firewall functions require this for their native operation with or without midcom. > The last time this was proposed > (by me) it met decidedly, uh, enthusiastic disagreement from > the working group. We're not going to be revisiting either > decision at this very late date. In summary, I am in agreement with what you say. I was not suggesting any of the items you were alludign to in the e-mail. > > Melinda > regards, suresh ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Sep 26 10:56:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09409 for ; Fri, 26 Sep 2003 10:56:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2u0t-00072Z-IT for midcom-archive@odin.ietf.org; Fri, 26 Sep 2003 10:56:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QEu7eE027062 for midcom-archive@odin.ietf.org; Fri, 26 Sep 2003 10:56:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2u0n-00071R-8a; Fri, 26 Sep 2003 10:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2tzr-0006yQ-Uh for midcom@optimus.ietf.org; Fri, 26 Sep 2003 10:55:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09343 for ; Fri, 26 Sep 2003 10:54:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2tzp-0001nW-00 for midcom@ietf.org; Fri, 26 Sep 2003 10:55:01 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A2tzo-0001mv-00 for midcom@ietf.org; Fri, 26 Sep 2003 10:55:00 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.9) with ESMTP id h8QEsIJ1096266; Fri, 26 Sep 2003 16:54:18 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 61D1FCC8B7; Fri, 26 Sep 2003 16:23:59 +0200 (CEST) Date: Fri, 26 Sep 2003 16:54:15 +0200 From: Martin Stiemerling To: Pyda Srisuresh , Tom Taylor , JXrgen_Quittek Cc: midcom@ietf.org Subject: Re: [midcom] Reminder: wg last call Message-ID: <26540000.1064588055@n-stiemerling.office> In-Reply-To: <20030920182150.12453.qmail@web40412.mail.yahoo.com> References: <20030920182150.12453.qmail@web40412.mail.yahoo.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: quoted-printable Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable here is the second part of my answer. Cheers Martin | Now, let us consider the case of PER transaction(section 2.3.8). PER in | the context of a NAT refers to the agent creating a NAT binding with | specific parameters. This will fail if the prameters specified in the | bind-create request donot correspond to one or more (in the case of | twice-NAT) address map entries. Without reference of an address map | entry, the agent has no knowledge of whether to request for an address | bind or a port bind. Assuming that A0 is given (as specified in PER and will be specified in PRR = in the upcoming version of the semantics), the middlebox knows the=20 corresponding mapping as well. The choice wether to do an address or port=20 map depends on the middlebox type and may depend on the requested=20 configuration as well (for instance if a binding for IP-only is requested). | Further, the binding is meaningless without the | exact session description to a symmetric NAPT. This is because symmetric | NAPT uses different port bindings for the same (private IP address, port) | tuple used in different sessions. The port bind may work only for the | first session that originates from (provate IP address, port). There are | other caveats. Without a PRR preceding the PER, how is the PER to know | what external address to bound to? Why not let the middlebox select the | external address to bound to? When I understand it in the correct way, you see the problem that the=20 middlebox many not be able to associate to reference certains configuration = in the NAT? But there is the policy rule identifier, which is not the=20 session or whatever identifier in the box, but it may correlate to that. Furthermore, the middlebox never can know the external address (as in=20 semantics terminology) by heart. The outside (I think that is what you are=20 referring to as external address) address is always determined by the=20 middlebox. | | This is why I suggested the tansactions CreateBind, CreateportBind, | RequestCreateBind, and RequestCreatePortBind to create binds | unequivocally. These transactions use address map as an argument. Either | the agent or the middlebox can create a bind. | | Creating binds is not adequate. The agent needs to be able to specify the | permitted sessions as well. Without going into the details, i will simply | suggest FTP(TCP based) and TFTP(UDP based) are examples of this. Perhaps the key point in our discussions is our use of 'NAT binding'? The pure NAT terminology says that a binding is (A0, A2) and a session is=20 (A0, A2, A3) and where are using the term of NAT binding more loosely.=20 Because in our view we are not interested whether a NAT binding, or session = is established. For example, when we refer to NAT binding in PER, we mean a = full configured policy rule for the middlebox (A0, A2, A3) that allows only = to traverse packets belonging to that specific data flow. But we have to=20 use some more loosely terminology due to the fact we handle a whole bunch=20 of different packet filter firewalls and network address translators. So we = need to talk more broad. Perhaps we should clearly mention that first and=20 foremost of the semantics, so that no or less confusions will come up. Martin | | This is why I suggested the tansactions CreateOutboundSesion, | CreateInboundSession, RequestCreateOutboundSession and | RequestCreateInboundSession to create sessions unequivocally. Either the | agent or the middlebox can create a session. | | As for twice-NAT, I am frankly confused by the PRR/PER transactions. | There was reference to using a singe policy rule identifier for two | address/port reservations and two binds. Assuming all the parameters | specified in a PER are adequate (which I dont believe, they are), the | requirement of using a new artificial handle to represent two independent | twice-nat bind is unnecessarily complex on the part of the middlebox. | |> I am |> not surprised to find MIB designers scratching their heads over how to |> reconcile the |> two points of view. | | MIB designers donot have a problem creating a MIB to run transactions. = MIB | designers are having to scratch their head because the Midcom semantics | works only in the simplest of cases. | |> My natural and naive inclination is to view the |> MIDCOM |> MIB as a |> logically separate beast. The NAT or firewall MIB would merely reflect |> the results |> of MIDCOM operations, rather than be tied to the MIDCOM MIB explicitly. | | I donot have a problem provided the the midcom transactions are | reasonable, complete and donot impose impossible requirements on the | middleboxes. It is my view that the transactions are most meanigful when | the transactions relate to the resources/objects the middlebox can relate | to. | |> |> I suppose the question is whether the abstract view is acceptable to |> implementors, |> or whether they will insist that any MIDCOM protocol addresses precisely |> the functions offered by their middlebox. If Pyda is representative of |> NAT implementors, the semantics need a bit of modification. | | I do believe, the transactions in the semantics document need | modification. If you like, I would be glad to work with the authors on | this. | | regards, | suresh | |> |> J=FCrgen Quittek wrote: |> |> > Pyda, |> > |> > Thanks for your comments. Please see replies to some of them inline. |> > |> > --On 06.09.2003 14:15 Uhr -0700 Pyda Srisuresh |> > wrote: |> > |> >> Below is text of the e-mail (a little revised) I sent to the authors |> >> earlier. I |> >> am including the text for wider audience. Below are my outstanding |> >> comments on |> >> the draft. |> >> |> >> 1. For a NAT middlebox, I believe, the semantics ought to cover the |> >> following |> >> transactions. My comments assume the following. |> >> |> >> A. NAT is configured on a per-interface basis. As such, the |> >> Midcom/NAT transactions would be specified on a |> >> per-interface basis. |> > |> > |> > I do not share this view. A midcom agent has the intention and |> > capability to specify endpoints of communication across the middlebox. |> > Which interfaces |> > of the middlebox are affected is not subject of midcom transactions. |> > |> > The MIDCOM information model simplifies the network view by just |> > separating an internal network and an external network. Whether or not |> > the middlebox has |> > one or more interfaces connected to any of them is considered an |> > internal matter |> > of the middlebox. |> > |> > There is no statement in framework or requirements that oblige an |> > agent to find |> > out which interfaces a middlebox is using. |> > |> >> B. End-point below is to be refered as >> TU-port> for a PortBind. End-point for an address Bind will be |> >> . The IP address can be V4 or V6. |> >> C. The transactions specified below can be applicable to one or |> >> more |> >> end-points. This will include address ranges, address |> >> wild-carding, port ranges, and port wild-carding. |> >> |> >> |> >> SetMapOwner [Full | Partial] [ >> Entry>] |> >> - SetMapowner may be used by an agent to claim |> >> ownership on a complete NAT map entry or a |> >> portion of the entry. AgentId will be set as |> >> the owner of the entire map entry or portion |> >> thereof. |> >> |> >> (CreateBind | CreatePortBind) |> >> >> End-point> |> >> - Agent specifies all the requisite Parameters |> >> for Bind(s) or PortBind(s). Agent requests |> >> middlebox to create a BIND and respond back |> >> with an |> >> assigned |> >> BindId. Middlebox to validate the |> >> authorization prior to responding. |> >> |> >> (RequestCreateBind | RequestPortCreateBind) |> >> [Oddity = option] |> >> - Agent requests the Middlebox to create |> >> BIND(s) |> >> for |> >> the given End-point, optionally with an = Oddity |> >> requirement. Middlebox to validate the |> >> authorization, prior to assgining a BIND and |> >> a BindId and returning the response. |> >> |> >> CreateOutboundSession |> >> | >> BindId> | >> end-point |> >> Bindid> |> >> |> >> |> >> - Agent specifies all the requisite Parameters |> >> for an outbound session. Agent requests |> >> middlebox to create a session as specified |> >> and respond back with an assigned BindId. |> >> The session may have one or two end-point |> >> translations. The session may be derived |> >> directly from the address map (or) from |> >> associated |> >> Bind-IDs. |> >> Middlebox to validate the authorization prior |> >> to responding. Note, the session tuple may |> >> have wild-card elements. |> >> |> >> RequestCreateOutboundSession |> >> | >> BindId> | >> end-point |> >> Bindid> |> >> |> >> - Agent requests the Middlebox to create an |> >> outbound |> >> session for the given session tuple, using |> >> one or more map entries and/or end-point |> >> BINDs. Agent to validate he authorization |> >> prior to responding back with a new session |> >> and session-id. As |> >> before, |> >> the session tuple may have wild-card = elements. |> >> |> >> CreateInboundSession, |> >> RequestCreateInboundSession |> >> - Similar to the outbound counterparts. |> >> |> >> ModifyBindParameters |> >> [] [MaximumIdletime>] [] |> >> - These parameters may be specified either at |> >> Bind creation time or later. |> >> |> >> ModifySessionParameters |> >> [] [MaximumIdletime>] [] |> >> - These parameters may be specified either at |> >> session |> >> creation time or later. Note, session here |> >> refers to the NAT data sessions, not the |> >> Midcom agent session. |> >> |> >> In particular, I would like to mention the notion of three resources |> >> a NAT middlebox and midcom agent need to be cognizant of - |> >> Address map entries, Binds and sessions. These resources may be a) |> >> created by |> >> the agent, b) created by the NAT middlebox, or c) paramaters modified |> >> by the |> >> agent. |> > |> > |> > The way I see it, MIDCOM does not distinguish binding and session (as |> > the NAT MIB does). |> > The point is that the MIDCOM protocol is not a middlebox management |> > protocol, but a |> > protocol that allows applications to express requests for enabling |> > communication |> > across a middlebox. |> > |> >> 2. The notion of PRR is incomplete without the context of the entire |> >> address |> >> map entry. The reservation may not be specific to |> >> address/address-port alone. |> >> My view of this is simply that PRR is just another notion of |> >> ownership claim. |> >> it just happens to be in relation to an address map entry. |> > |> > |> > The intention behind PRR is just to reserve addresses at the = middlebox. |> > This can be doen without mapping them already. |> > |> >> 3. When you combine the notion of PRR wth PER, the state transition |> >> diagram in |> >> section 2.3.13 woudl be simplified, with the proviso that there would |> >> be three |> >> types of policy rules (address map entries, binds and sessions). |> > |> > |> > Again, binds and sessions cannot be distinguished in the midcom world. |> > |> >> 4. I agree with your notion of Session establishment and session |> >> termination |> >> transactions. |> >> |> >> 5. I believe, the group Ids an agent would use during the lifetime of |> >> a Midcom |> >> session should be specified by the agent - either at the midcom |> >> session establishment time or afterwards whild the midcom session is |> >> alive. Given that |> >> group-Ids are specific to an agent, it shoudl be agent's |> >> responsibility to |> >> assign group IDs, not that of the middlebox's. Further, given that |> >> there are 3 |> > |> > |> > Group IDs need to be unique per middlebox. |> > This is hard to achieve if the agent assigns them. |> > |> >> different types of resources (map entries, Binds and sessions), there |> >> shoudl be |> >> three different sets of group-Ids, one set for each resource type. |> >> Middlebox will assign a default groupId of 0 to all entities that are |> >> not assigned a groupId by the agent. |> > |> > |> > I prefer to have reservation rules and enable rules (bindings) to be |> > able to share a group. because then the agent can extend or delete |> > sets of them belonging together by just accessing a single group. |> > |> > Cheers, |> > |> > Juergen |> | | | =3D=3D=3D=3D=3D | _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Fri Sep 26 11:13:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10242 for ; Fri, 26 Sep 2003 11:13:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2uHE-0008NR-TJ for midcom-archive@odin.ietf.org; Fri, 26 Sep 2003 11:13:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QFD0fE032184 for midcom-archive@odin.ietf.org; Fri, 26 Sep 2003 11:13:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2uHD-0008Md-Kz; Fri, 26 Sep 2003 11:12:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2uGa-0008MH-T1 for midcom@optimus.ietf.org; Fri, 26 Sep 2003 11:12:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10218 for ; Fri, 26 Sep 2003 11:12:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2uGa-00024W-00 for midcom@ietf.org; Fri, 26 Sep 2003 11:12:20 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1A2uGZ-00023x-00 for midcom@ietf.org; Fri, 26 Sep 2003 11:12:19 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.9) with ESMTP id h8QFBmJ1096612; Fri, 26 Sep 2003 17:11:48 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B5C617D69A; Fri, 26 Sep 2003 16:41:29 +0200 (CEST) Date: Fri, 26 Sep 2003 17:11:45 +0200 From: Martin Stiemerling To: Pyda Srisuresh , midcom@ietf.org Subject: Re: [midcom] WG feedback solicited - Midcom semantics Message-ID: <37910000.1064589105@n-stiemerling.office> In-Reply-To: <20030925140354.76240.qmail@web40405.mail.yahoo.com> References: <20030925140354.76240.qmail@web40405.mail.yahoo.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi folks, --On Thursday, September 25, 2003 07:03:54 -0700 Pyda Srisuresh wrote: | Folks, | | The authors and I are unable to make much progress due to a basic | conflict in our perception of the Midcom objective and how to go about | it. The authors and I discussed over the phone yesterday and decided that | we post you this e-mail so you can provide the feedback. Your feedback | will be valuable in order to make progress. Thank you. Right, and we would really appreciate comments from the mailing list about the issues. | | 1. I believe, the objective of the Midcom protocol (and hence the | semantics) is to keep the middleboxes simple, without requiring ALGs. Right, keeping the ALGs out of the middlebox. | Agents will control middlebox resources (via midcom) to allow the | end-2-end applications to work. As such, the middleboxes should permit | their resources to be controlled by agents via the midcom protocol. That's agreed, but controlling resources may be to broad, since ALGs want to enable communication end-to- and they do not want to deal with middlebox internal issues. | | The authors believe (Correct me if I am wrong) that the objective of the | semantics is to require the agents to be as simple as possible in their | interactions with middlebox. The complexity should be moved to the | middlebox. The complexity should stay there where it is anyway: - full configuration of middleboxes with all their resources, plus their internal configuration, mode of operation, and implementation issues should stay in the middlebox - handling of application logic should stay at the ALGs/proxies. But application logic should not be loaded with middlebox issues, otherwise the actual gain of simplicity would be gone, at least for the ALGs. | | 2. I believe, in order for the agents to control middlebox resources, the | agents ought to have the knowledge of the middlebox configuration. | - Relevent interface, NAT address map entries, | default MaxIdleTimeouts configured. | - Relevant interface specific firewall filters configured. | | The authors believe (correct me, if I am wrong), the agent should not | have to know the middlebox configuration in order to run midcom protocol. The agent should be able to dynamically configure policy rules at middleboxes without (or even less) knowledge. That's keep it simple, stupid. Martin | | 3. Lastly, I believe, the midcom protocol should allow agents to control | all middlebox resources and parameters. | Midcom protocol should be aware | of the middlebox resources and be designed to execute on these resources. | Specifically, the resource for a NAT middlebox are: NAT address map | entries, address/port bindings, and sessions. NAT controllable parameters | are: MaxIdleTimeouts for bindings and sessions. The resources for a | firewall are: permit/deny packet filters. Further to these native | parameters, Midcom requires the middleboxes to support a) resource | Lifetimes, b) resource Grouping and b) asynchronous notification for the | resources the agents control. A middlebox should incorporate these into | its resources to support midcom. | | The authors create an abstract model of resources for midcom protocol and | mandate middleboxes to meet that abstract resource model. In the semantics | model, the authors argue, there ought to be a one-to-one relationship | between bindings and sessions and that the middlebox should figure out | how to make this happen. The authors donot care to know if a session had | 2 bindings, 1 binding or had no binding. | | Well, thats all for now. Thank you. | | regards, | suresh | | | | ===== | | | _______________________________________________ | midcom mailing list | midcom@ietf.org | https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Sep 29 09:54:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15115 for ; Mon, 29 Sep 2003 09:54:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3yTT-0003nf-A2 for midcom-archive@odin.ietf.org; Mon, 29 Sep 2003 09:54:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TDs3VB014601 for midcom-archive@odin.ietf.org; Mon, 29 Sep 2003 09:54:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3yTR-0003mt-7X; Mon, 29 Sep 2003 09:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3ySt-0003hb-5z for midcom@optimus.ietf.org; Mon, 29 Sep 2003 09:53:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14985 for ; Mon, 29 Sep 2003 09:53:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3ySr-00064W-00 for midcom@ietf.org; Mon, 29 Sep 2003 09:53:25 -0400 Received: from web40408.mail.yahoo.com ([66.218.78.105]) by ietf-mx with smtp (Exim 4.12) id 1A3ySq-00063U-00 for midcom@ietf.org; Mon, 29 Sep 2003 09:53:24 -0400 Message-ID: <20030929135252.35796.qmail@web40408.mail.yahoo.com> Received: from [67.164.29.130] by web40408.mail.yahoo.com via HTTP; Mon, 29 Sep 2003 06:52:52 PDT Date: Mon, 29 Sep 2003 06:52:52 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] WG feedback solicited - Midcom semantics To: Martin Stiemerling , midcom@ietf.org In-Reply-To: <37910000.1064589105@n-stiemerling.office> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --- Martin Stiemerling wrote: > Hi folks, > > --On Thursday, September 25, 2003 07:03:54 -0700 Pyda Srisuresh > wrote: > > | Folks, > | > | The authors and I are unable to make much progress due to a basic > | conflict in our perception of the Midcom objective and how to go about > | it. The authors and I discussed over the phone yesterday and decided that > | we post you this e-mail so you can provide the feedback. Your feedback > | will be valuable in order to make progress. Thank you. > > Right, and we would really appreciate comments from the mailing list about > the issues. > | > | 1. I believe, the objective of the Midcom protocol (and hence the > | semantics) is to keep the middleboxes simple, without requiring ALGs. > > Right, keeping the ALGs out of the middlebox. > > | Agents will control middlebox resources (via midcom) to allow the > | end-2-end applications to work. As such, the middleboxes should permit > | their resources to be controlled by agents via the midcom protocol. > > That's agreed, but controlling resources may be to broad, since ALGs want > to enable communication end-to- and they do not want to deal with middlebox > internal issues. >^^^^^^^^^^^^^^^^ What middlebox internal issues? I was only refering to middlebox resources. You donot need to understand routing protocols to program a router. But, you do need to understand route object and how a router uses routes in order to program the router. > | > | The authors believe (Correct me if I am wrong) that the objective of the > | semantics is to require the agents to be as simple as possible in their > | interactions with middlebox. The complexity should be moved to the > | middlebox. > > The complexity should stay there where it is anyway: > - full configuration of middleboxes with all their resources, plus their > internal configuration, mode of operation, and implementation issues should > stay in the middlebox Agreed. Configuration and bringup of a middlebox, just as configuration and bringup of an application is independent of midcom. > - handling of application logic should stay at the ALGs/proxies. Yes. > > But application logic should not be loaded with middlebox issues, otherwise ^^^^^^ That is what an ALG does. An ALG has to know how to control middlebox resources. You cannot be an ALG and not understand middlebox resources. > the actual gain of simplicity would be gone, at least for the ALGs. The simplicity is moving ALGs out of middlebox. This reamins. > > | > | 2. I believe, in order for the agents to control middlebox resources, the > | agents ought to have the knowledge of the middlebox configuration. > | - Relevent interface, NAT address map entries, > | default MaxIdleTimeouts configured. > | - Relevant interface specific firewall filters configured. > | > | The authors believe (correct me, if I am wrong), the agent should not > | have to know the middlebox configuration in order to run midcom protocol. > > The agent should be able to dynamically configure policy rules at > middleboxes without (or even less) knowledge. That's keep it simple, stupid. The ALG (agent) should know the configuration of the middlebox it is interfacing with. The ALG will not be able to control middelbox resources blindly. > > > Martin > > > | > | 3. Lastly, I believe, the midcom protocol should allow agents to control > | all middlebox resources and parameters. > | Midcom protocol should be aware > | of the middlebox resources and be designed to execute on these resources. > | Specifically, the resource for a NAT middlebox are: NAT address map > | entries, address/port bindings, and sessions. NAT controllable parameters > | are: MaxIdleTimeouts for bindings and sessions. The resources for a > | firewall are: permit/deny packet filters. Further to these native > | parameters, Midcom requires the middleboxes to support a) resource > | Lifetimes, b) resource Grouping and b) asynchronous notification for the > | resources the agents control. A middlebox should incorporate these into > | its resources to support midcom. > | > | The authors create an abstract model of resources for midcom protocol and > | mandate middleboxes to meet that abstract resource model. In the semantics > | model, the authors argue, there ought to be a one-to-one relationship > | between bindings and sessions and that the middlebox should figure out > | how to make this happen. The authors donot care to know if a session had > | 2 bindings, 1 binding or had no binding. > | > | Well, thats all for now. Thank you. > | > | regards, > | suresh > | > | > | > | ===== cheers, suresh ===== _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Sep 29 10:02:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15576 for ; Mon, 29 Sep 2003 10:02:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3ybC-00043C-AI for midcom-archive@odin.ietf.org; Mon, 29 Sep 2003 10:02:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TE22wP015554 for midcom-archive@odin.ietf.org; Mon, 29 Sep 2003 10:02:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3ybB-00042Z-B5; Mon, 29 Sep 2003 10:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3nWM-0005Xn-Ri for midcom@optimus.ietf.org; Sun, 28 Sep 2003 22:12:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08857 for ; Sun, 28 Sep 2003 22:12:09 -0400 (EDT) From: Rohit.Mehendiratta@utstar.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3nWJ-0007BE-00 for midcom@ietf.org; Sun, 28 Sep 2003 22:12:15 -0400 Received: from quartz.mw.3com.com ([192.65.73.145]) by ietf-mx with esmtp (Exim 4.12) id 1A3nWJ-0007BB-00 for midcom@ietf.org; Sun, 28 Sep 2003 22:12:15 -0400 Received: from gypsum.mw.3com.com (gypsum.mw.3com.com [149.112.20.3]) by quartz.mw.3com.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h8T2HmfH018864; Sun, 28 Sep 2003 19:17:48 -0700 (PDT) Received: from utstarchi01.mw.3com.com (uschi001.mw.3com.com [149.112.142.9]) by gypsum.mw.3com.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h8T2CtNl026382; Sun, 28 Sep 2003 19:12:55 -0700 (PDT) Subject: Re: [midcom] Re: Fwd: RE: NAT-MIB review To: j.schoenwaelder@iu-bremen.de Cc: bwijnen@lucent.com, npai@cisco.com, raraghun@cisco.com, srisuresh@yahoo.com, cliffwang2000@yahoo.com, midcom@ietf.org, rrohit74@hotmail.com Date: Sun, 28 Sep 2003 21:12:06 -0500 Message-ID: X-MIMETrack: Serialize by Router on UTSTARCHI01/UTStarcom(Release 5.0.12 |February 13, 2003) at 09/28/2003 09:12:10 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Juergen, I have started working on the comments and you should expect the new draft and communitcation to the midcom related to the changes on or before 10/19. Thanks Rohit Juergen Schoenwaelder on 09/17/2003 01:24:10 AM Please respond to j.schoenwaelder@iu-bremen.de To: Rohit Mehendiratta/C/UTStarcom@UTStarcom cc: bwijnen@lucent.com, npai@cisco.com, raraghun@cisco.com, srisuresh@yahoo.com, cliffwang2000@yahoo.com, midcom@ietf.org, rrohit74@hotmail.com Subject: Re: [midcom] Re: Fwd: RE: NAT-MIB review On Mon, Sep 15, 2003 at 01:02:56AM -0500, Rohit.Mehendiratta@utstar.com wrote: > 1. As Suresh also mentioned that Midcom MIB is not published yet; thats > why MIDCOM Compliance/Owner Id/Group Id may not make much sense. > What should we do in this case ? As I wrote in another email: Either wait until the MIDCOM MIB is ready to go as well or put these objects in place at a later point in time by using AUGMENTS or whatever is a good choice to handle things. > 2. > > > > > > > 7) Section 4.3 says that binds which point to non-existing address > > > > maps are not allowed. In the MIB definitions, it would be very > > > > useful to say precisely what happens if one tries to violate the > > > > rule (that is, which error code is actually generated when I try > > > > to delete an address map with pending binds or try to create a > > > > bind which points to a non-existing address map). > > In the last revision, i had mentioned snmp error code as > inconsistentErrorValue but there were comments that this error code > is only specific to some snmp version and hence > we shouldn't mention it. I would like to know your opinion on the same. The formal argument would be that inconsistentValue is part of the official SNMP standard and everything else is historic. The more useful response is that there is a well-defined mapping of SNMPv3 error codes to SNMPv1 error codes, see RFC 3584 section 4.4. > 3. I will remove storageType objects on the next version as i don't see > much use of them in this MIB. > Let me know your opinion about the same. The MIB review guidelines say that you should have StorageType columns on tables that have RowStatus columns. Why do you think a storage type is not of much use? Do you assume that all the rows created by a manager are volatile on all implementations? > 4. It is my undretstaning that in most of the customer scenarios, the binds > and sessions are generated dynamically while addrmaps are configured. > Thats why we have separate branches for config and translation. > Even if the bind and session have the rowStatus, i don't anticipate > it to be used widely. I am not sure whether it helps anyone to have different branches for things that are configured and things that are not (or unlikely to be configured). But despite this debatable view of the world, I am wondering why some tables have RowStatus columns which you do not consider to be used for configuration... > 5. Related to notification changes, we will simplify it a lot in the next > version. OK. But it would be good to get the WG involved in the changes and to have the WG agree to the changes. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Sep 29 10:55:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19030 for ; Mon, 29 Sep 2003 10:55:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zQa-0006oJ-Kv for midcom-archive@odin.ietf.org; Mon, 29 Sep 2003 10:55:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TEt8ap026178 for midcom-archive@odin.ietf.org; Mon, 29 Sep 2003 10:55:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zQV-0006nG-6W; Mon, 29 Sep 2003 10:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zPY-0006lH-4D for midcom@optimus.ietf.org; Mon, 29 Sep 2003 10:54:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18942 for ; Mon, 29 Sep 2003 10:53:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3zPV-0006sz-00 for midcom@ietf.org; Mon, 29 Sep 2003 10:54:01 -0400 Received: from web40413.mail.yahoo.com ([66.218.78.110]) by ietf-mx with smtp (Exim 4.12) id 1A3zPU-0006s2-00 for midcom@ietf.org; Mon, 29 Sep 2003 10:54:00 -0400 Message-ID: <20030929145330.32492.qmail@web40413.mail.yahoo.com> Received: from [67.164.29.130] by web40413.mail.yahoo.com via HTTP; Mon, 29 Sep 2003 07:53:30 PDT Date: Mon, 29 Sep 2003 07:53:30 -0700 (PDT) From: Pyda Srisuresh Subject: Re: [midcom] Reminder: wg last call To: Martin Stiemerling , Tom Taylor , JXrgen_Quittek Cc: midcom@ietf.org In-Reply-To: <26540000.1064588055@n-stiemerling.office> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA18943 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable --- Martin Stiemerling wrote: > here is the second part of my answer. >=20 > Cheers > Martin >=20 >=20 > | Now, let us consider the case of PER transaction(section 2.3.8). PER = in > | the context of a NAT refers to the agent creating a NAT binding with > | specific parameters. This will fail if the prameters specified in the > | bind-create request donot correspond to one or more (in the case of > | twice-NAT) address map entries. Without reference of an address map > | entry, the agent has no knowledge of whether to request for an addres= s > | bind or a port bind. >=20 > Assuming that A0 is given (as specified in PER and will be specified in= PRR=20 > in the upcoming version of the semantics), the middlebox knows the=20 > corresponding mapping as well.=20 Just to be clear, the middelbox has to know the full tuple of the session= A0 is initiating in order to determine which of its address map entries will be applicable. Ex: (A0, SrcPort, A1, DestPort-on-A1) or (A0, SrcPort, A3, DestPort-on-A3).=20 > The choice wether to do an address or p= ort=20 > map depends on the middlebox type=20 ^^^^^^^^^^^^^^ Assuming this is the first packet of a session, address map entries on th= e middlebox determine which of the fields in the session will undergo translation. This may be source adress (and port), destination address (a= nd port) or both. > and may depend on the requested=20 ^^^^^^^^^ > configuration as well (for instance if a binding for IP-only is request= ed). ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^ I assume, you are refering to midcom "requests" here. What is a midcom co= nfig request? Midcom will not configure new address map entries on the middleb= ox. An agent may make binding requests, only so long as it is meaningful and = refers to an address map.=20 >=20 > | Further, the binding is meaningless without the > | exact session description to a symmetric NAPT. This is because symmet= ric > | NAPT uses different port bindings for the same (private IP address, p= ort) > | tuple used in different sessions. The port bind may work only for the > | first session that originates from (provate IP address, port). There = are > | other caveats. Without a PRR preceding the PER, how is the PER to kno= w > | what external address to bound to? Why not let the middlebox select t= he > | external address to bound to? >=20 > When I understand it in the correct way, you see the problem that the=20 > middlebox many not be able to associate to reference certains configura= tion=20 > in the NAT? But there is the policy rule identifier, which is not the=20 > session or whatever identifier in the box, but it may correlate to that. How?=20 I think, you are saying that PER has all the information an application n= eeds. Let the middlebox figure out how this relates to its objects. Let us purs= ue this further. Policy Rule Identifier is empty when there is no PRR preceding. If PER ha= s all the original session parameters as seen by A0 or A3, NAT can use this to = set a NAT flow, if there isnt one existing and return back the NAT flow handle(= also called NAT session handle in previous e-mails), provided it knows the int= erface context of the session. This would be same as requesting a NAT session. I= s this what you are talking about? When Policy Rule Identifier is non-empty (as in filled with a previous PR= R rule handle), the policy rule identifier would presumably contain all the translation parameters for that session. However, PRR as described in the document, does not contain BINDs, but a bunch of address/port reservation= s from one or more address map entries. This is why, I suggested splitting this up into (a) ownership claims on full/partial map entries, and (b) setting/requesting address/port bndings. Once the midcom transactions, as existing, are redefined as instruments o= n top of middlebox resources, the whole thing thign will make more sense. Furth= er, the semantica model can be enriched with transactions not defined as yet. > Furthermore, the middlebox never can know the external address (as in=20 > semantics terminology) by heart. The outside (I think that is what you = are=20 > referring to as external address) address is always determined by the=20 > middlebox. >=20 > | > | This is why I suggested the tansactions CreateBind, CreateportBind, > | RequestCreateBind, and RequestCreatePortBind to create binds > | unequivocally. These transactions use address map as an argument. Eit= her > | the agent or the middlebox can create a bind. > | > | Creating binds is not adequate. The agent needs to be able to specify= the > | permitted sessions as well. Without going into the details, i will si= mply > | suggest FTP(TCP based) and TFTP(UDP based) are examples of this. >=20 > Perhaps the key point in our discussions is our use of 'NAT binding'? That certainly sounds like one of the key items. > The pure NAT terminology says that a binding is (A0, A2) Yes. > and a session = is=20 > (A0, A2, A3) and=20 ^^^^^^^^^^^^ Yes, in case of traditional NAT. That is what a NAT session (or NAT flow)= would represent for a traditional NAT. > where are using the term of NAT binding more loosel= y.=20 Sounds like it. You do bring up a good point. > Because in our view we are not interested whether a NAT binding, or ses= sion=20 > is established. For example, when we refer to NAT binding in PER, we me= an a=20 > full configured policy rule for the middlebox (A0, A2, A3) that allows = only=20 > to traverse packets belonging to that specific data flow.=20 OK. This is what I refer to as NAT session or NAT flow. This is a native = NAT resource. I see no problem with NAT middlebox returning this.=20 > But we have t= o=20 > use some more loosely terminology due to the fact we handle a whole bun= ch=20 > of different packet filter firewalls and network address translators.=20 I disagree. This would not be the case if the semantics document identifi= ed transactions based on middlebox resources instead of abstracting them. > S= o we=20 > need to talk more broad. Perhaps we should clearly mention that first a= nd=20 > foremost of the semantics, so that no or less confusions will come up. I continue to believe, the right approach is not to proliferate with more terms, but work with the resources of middlebox functions. >=20 > Martin >=20 cheers, suresh >=20 > | > | This is why I suggested the tansactions CreateOutboundSesion, > | CreateInboundSession, RequestCreateOutboundSession and > | RequestCreateInboundSession to create sessions unequivocally. Either = the > | agent or the middlebox can create a session. > | > | As for twice-NAT, I am frankly confused by the PRR/PER transactions. > | There was reference to using a singe policy rule identifier for two > | address/port reservations and two binds. Assuming all the parameters > | specified in a PER are adequate (which I dont believe, they are), the > | requirement of using a new artificial handle to represent two indepen= dent > | twice-nat bind is unnecessarily complex on the part of the middlebox. > | > |> I am > |> not surprised to find MIB designers scratching their heads over how = to > |> reconcile the > |> two points of view. > | > | MIB designers donot have a problem creating a MIB to run transactions= . MIB > | designers are having to scratch their head because the Midcom semanti= cs > | works only in the simplest of cases. > | > |> My natural and naive inclination is to view the > |> MIDCOM > |> MIB as a > |> logically separate beast. The NAT or firewall MIB would merely refl= ect > |> the results > |> of MIDCOM operations, rather than be tied to the MIDCOM MIB explicit= ly. > | > | I donot have a problem provided the the midcom transactions are > | reasonable, complete and donot impose impossible requirements on the > | middleboxes. It is my view that the transactions are most meanigful w= hen > | the transactions relate to the resources/objects the middlebox can re= late > | to. > | > |> > |> I suppose the question is whether the abstract view is acceptable to > |> implementors, > |> or whether they will insist that any MIDCOM protocol addresses preci= sely > |> the functions offered by their middlebox. If Pyda is representativ= e of > |> NAT implementors, the semantics need a bit of modification. > | > | I do believe, the transactions in the semantics document need > | modification. If you like, I would be glad to work with the authors o= n > | this. > | > | regards, > | suresh > | > |> > |> J=FCrgen Quittek wrote: > |> > |> > Pyda, > |> > > |> > Thanks for your comments. Please see replies to some of them inlin= e. > |> > > |> > --On 06.09.2003 14:15 Uhr -0700 Pyda Srisuresh > |> > wrote: > |> > > |> >> Below is text of the e-mail (a little revised) I sent to the auth= ors > |> >> earlier. I > |> >> am including the text for wider audience. Below are my outstandin= g > |> >> comments on > |> >> the draft. > |> >> > |> >> 1. For a NAT middlebox, I believe, the semantics ought to cover t= he > |> >> following > |> >> transactions. My comments assume the following. > |> >> > |> >> A. NAT is configured on a per-interface basis. As such, the > |> >> Midcom/NAT transactions would be specified on a > |> >> per-interface basis. > |> > > |> > > |> > I do not share this view. A midcom agent has the intention and > |> > capability to specify endpoints of communication across the middle= box. > |> > Which interfaces > |> > of the middlebox are affected is not subject of midcom transaction= s. > |> > > |> > The MIDCOM information model simplifies the network view by just > |> > separating an internal network and an external network. Whether or= not > |> > the middlebox has > |> > one or more interfaces connected to any of them is considered an > |> > internal matter > |> > of the middlebox. > |> > > |> > There is no statement in framework or requirements that oblige an > |> > agent to find > |> > out which interfaces a middlebox is using. > |> > > |> >> B. End-point below is to be refered as |> >> TU-port> for a PortBind. End-point for an address Bind will= be > |> >> . The IP address can be V4 or V6. > |> >> C. The transactions specified below can be applicable to on= e or > |> >> more > |> >> end-points. This will include address ranges, address > |> >> wild-carding, port ranges, and port wild-carding. > |> >> > |> >> > |> >> SetMapOwner [Full | Partial] [ |> >> Entry>] > |> >> - SetMapowner may be used by an agent to cl= aim > |> >> ownership on a complete NAT map entry or = a > |> >> portion of the entry. AgentId will be set= as > |> >> the owner of the entire map entry or port= ion > |> >> thereof. > |> >> > |> >> (CreateBind | CreatePortBind) > |> >> |> >> End-point> > |> >> - Agent specifies all the requisite Paramet= ers > |> >> for Bind(s) or PortBind(s). Agent requests > |> >> middlebox to create a BIND and respond ba= ck > |> >> with an > |> >> assigned > |> >> BindId. Middlebox to validate the > |> >> authorization prior to responding. > |> >> > |> >> (RequestCreateBind | RequestPortCreateBind) > |> >> [Oddity op= tion] > |> >> - Agent requests the Middlebox to create > |> >> BIND(s) > |> >> for > |> >> the given End-point, optionally with an O= ddity > |> >> requirement. Middlebox to validate the > |> >> authorization, prior to assgining a BIND = and > |> >> a BindId and returning the response. > |> >> > |> >> CreateOutboundSession > |> >> | |> >> BindId> | |> >> end-point > |> >> Bindid> > |> >> > |> >> > |> >> - Agent specifies all the requisite Paramet= ers > |> >> for an outbound session. Agent requests > |> >> middlebox to create a session as specifie= d > |> >> and respond back with an assigned BindId. > |> >> The session may have one or two end-point > |> >> translations. The session may be derived > |> >> directly from the address map (or) from > |> >> associated > |> >> Bind-IDs. > |> >> Middlebox to validate the authorization p= rior > |> >> to responding. Note, the session tuple ma= y > |> >> have wild-card elements. > |> >> > |> >> RequestCreateOutboundSession > |> >> | |> >> BindId> | |> >> end-point > |> >> Bindid> > |> >> > |> >> - Agent requests the Middlebox to create an > |> >> outbound > |> >> session for the given session tuple, usin= g > |> >> one or more map entries and/or end-point > |> >> BINDs. Agent to validate he authorization > |> >> prior to responding back with a new sessi= on > |> >> and session-id. As > |> >> before, > |> >> the session tuple may have wild-card elem= ents. > |> >> > |> >> CreateInboundSession, > |> >> RequestCreateInboundSession > |> >> - Similar to the outbound counterparts. > |> >> > |> >> ModifyBindParameters > |> >> [] [MaximumIdletime>] [] > |> >> - These parameters may be specified either = at > |> >> Bind creation time or later. > |> >> > |> >> ModifySessionParameters > |> >> [] [MaximumIdletime>] [] > |> >> - These parameters may be specified either = at > |> >> session > |> >> creation time or later. Note, session her= e > |> >> refers to the NAT data sessions, not the > |> >> Midcom agent session. > |> >> > |> >> In particular, I would like to mention the notion of three resour= ces > |> >> a NAT middlebox and midcom agent need to be cognizant of - > |> >> Address map entries, Binds and sessions. These resources may be a= ) > |> >> created by > |> >> the agent, b) created by the NAT middlebox, or c) paramaters modi= fied > |> >> by the > |> >> agent. > |> > > |> > > |> > The way I see it, MIDCOM does not distinguish binding and session = (as > |> > the NAT MIB does). > |> > The point is that the MIDCOM protocol is not a middlebox managemen= t > |> > protocol, but a > |> > protocol that allows applications to express requests for enabling > |> > communication > |> > across a middlebox. > |> > > |> >> 2. The notion of PRR is incomplete without the context of the ent= ire > |> >> address > |> >> map entry. The reservation may not be specific to > |> >> address/address-port alone. > |> >> My view of this is simply that PRR is just another notion of > |> >> ownership claim. > |> >> it just happens to be in relation to an address map entry. > |> > > |> > > |> > The intention behind PRR is just to reserve addresses at the middl= ebox. > |> > This can be doen without mapping them already. > |> > > |> >> 3. When you combine the notion of PRR wth PER, the state transiti= on > |> >> diagram in > |> >> section 2.3.13 woudl be simplified, with the proviso that there w= ould > |> >> be three > |> >> types of policy rules (address map entries, binds and sessions). > |> > > |> > > |> > Again, binds and sessions cannot be distinguished in the midcom wo= rld. > |> > > |> >> 4. I agree with your notion of Session establishment and session > |> >> termination > |> >> transactions. > |> >> > |> >> 5. I believe, the group Ids an agent would use during the lifetim= e of > |> >> a Midcom > |> >> session should be specified by the agent - either at the midcom > |> >> session establishment time or afterwards whild the midcom session= is > |> >> alive. Given that > |> >> group-Ids are specific to an agent, it shoudl be agent's > |> >> responsibility to > |> >> assign group IDs, not that of the middlebox's. Further, given tha= t > |> >> there are 3 > |> > > |> > > |> > Group IDs need to be unique per middlebox. > |> > This is hard to achieve if the agent assigns them. > |> > > |> >> different types of resources (map entries, Binds and sessions), t= here > |> >> shoudl be > |> >> three different sets of group-Ids, one set for each resource type. > |> >> Middlebox will assign a default groupId of 0 to all entities that= are > |> >> not assigned a groupId by the agent. > |> > > |> > > |> > I prefer to have reservation rules and enable rules (bindings) to = be > |> > able to share a group. because then the agent can extend or delete > |> > sets of them belonging together by just accessing a single group. > |> > > |> > Cheers, > |> > > |> > Juergen > |> > | > | > | =3D=3D=3D=3D=3D > | >=20 >=20 >=20 >=20 =3D=3D=3D=3D=3D _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Sep 29 15:38:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06637 for ; Mon, 29 Sep 2003 15:38:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43qR-0006Xk-SF for midcom-archive@odin.ietf.org; Mon, 29 Sep 2003 15:38:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TJc7Fn025148 for midcom-archive@odin.ietf.org; Mon, 29 Sep 2003 15:38:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43qL-0006W7-Uo; Mon, 29 Sep 2003 15:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43q0-0006R2-Rv for midcom@optimus.ietf.org; Mon, 29 Sep 2003 15:37:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06420; Mon, 29 Sep 2003 15:37:33 -0400 (EDT) Message-Id: <200309291937.PAA06420@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: Mon, 29 Sep 2003 15:37:32 -0400 Subject: [midcom] I-D ACTION:draft-ford-midcom-p2p-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Peer-to-Peer communication across Middleboxes Author(s) : B. Ford, P. Srisuresh, D. Kegel Filename : draft-ford-midcom-p2p-00.txt Pages : 28 Date : 2003-9-29 This memo documents the methods which the current peer-to-peer (P2P) applications use to communicate in the presence of middleboxes such as firewalls and network address translators (NAT). Further, the document proposes a new middlebox IP option to allow deployment of P2P applications more effectively without significant rework on the middleboxes or the applications. The goal of this document is to enable immediate, wider deployment of P2P applications without requiring the use of special proxy, relay or midcom protocols, while not precluding their use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ford-midcom-p2p-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-ford-midcom-p2p-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-ford-midcom-p2p-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: <2003-9-29152829.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ford-midcom-p2p-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ford-midcom-p2p-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29152829.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From exim@www1.ietf.org Mon Sep 29 16:25:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10054 for ; Mon, 29 Sep 2003 16:25:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44Zv-00018K-U2 for midcom-archive@odin.ietf.org; Mon, 29 Sep 2003 16:25:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TKP737004331 for midcom-archive@odin.ietf.org; Mon, 29 Sep 2003 16:25:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44Zq-00017k-Gq; Mon, 29 Sep 2003 16:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44Z1-00016d-Uw for midcom@optimus.ietf.org; Mon, 29 Sep 2003 16:24:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09919 for ; Mon, 29 Sep 2003 16:24:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A44Z0-0004ZC-00 for midcom@ietf.org; Mon, 29 Sep 2003 16:24:10 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A44Yz-0004Yj-00 for midcom@ietf.org; Mon, 29 Sep 2003 16:24:09 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8TKNcJs009523 for ; Mon, 29 Sep 2003 13:23:38 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-43.cisco.com [10.32.241.43]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AMP99208; Mon, 29 Sep 2003 13:23:37 -0700 (PDT) Date: Mon, 29 Sep 2003 16:23:35 -0400 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Melinda Shore To: midcom@ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [midcom] IETF 58 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit It's time to start thinking about the upcoming meeting. Right now I'm planning on requesting a 1-hour slot. The two items on the agenda so far are a status update and discussion of the MIB work. Please let me know if there's anything else that needs meeting time, with the caveat that no meeting time will be devoted to anything that hasn't been discussed on the mailing list first. (Conversely, if there's something you feel needs meeting time, this is the right time to start discussion here.) Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom