From mailnull@www1.ietf.org Mon Mar 3 10:50:44 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 KAA00398 for ; Mon, 3 Mar 2003 10:50:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23G0lW28947 for midcom-archive@odin.ietf.org; Mon, 3 Mar 2003 11:00:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23G03p28889; Mon, 3 Mar 2003 11:00:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23Fu6p28596 for ; Mon, 3 Mar 2003 10:56:06 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00225 for ; Mon, 3 Mar 2003 10:45:32 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.155]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h23FlbYH007909; Mon, 3 Mar 2003 10:47:38 -0500 (EST) Message-ID: <3E637915.1050309@dynamicsoft.com> Date: Mon, 03 Mar 2003 10:47:33 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kristoffer Gronowski CC: midcom@ietf.org Subject: Re: [midcom] STUN ietf-draft 05 References: 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 Thanks for the feedback. I will get it changed to 0x01. Thanks for catching this! -Jonathan R. Kristoffer Gronowski wrote: > We have been testing STUN clients and servers on SipIt in Stockholm this week. > The majority used 0x01 for IPv4 so Rohan Mahy suggested that we should report this as > a typo. I believe that it would be more people out there that feels the same way. > It's not a big problem since one have to redo and check the current implementation when STUN > becomes a RFC. > But my vote is to change it back to 0x01. > > //Regards Stoffe! > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: den 28 februari 2003 02:29 > To: Panayiotis A. Thermos > Cc: midcom@ietf.org; petrovic@corp.earthlink.net > Subject: Re: [midcom] STUN ietf-draft 05 > > > I wish I had a better answer, but I have no idea why this changed. It > could be that it was a copy-paste error that got snuck in when that > paragraph was rewritten. > > STUN is now in auth48, so it is conceivable to change it back, although > I am not sure that is the right thing. Can people let me know which > value they are using in their implementations today? > > Thanks, > Jonathan R. > > Panayiotis A. Thermos wrote: > >>greetings, >> >>Marc Petrovic pointed to me that an early implementation >>of STUN at ( http://www.columbia.edu/~pt81/cs6901-08/cs6901-08.html) >>is setting the family field value of a STUN mesage, to 01 instead of 02 >>(to indicate family IPv4) as it is noted in the the latest STUN draft. >>Earlier versions of the draft state to set the value to 02 (when using >>IPv6). >>Was this intented, and if so, what is the rationale behind it? >> >>Peter >> >>PS: For those interested, I will be posting a new STUN implementation at >>the above URL soon after >> the SIPit event this week. >> >>_______________________________________________ >>midcom mailing list >>midcom@ietf.org >>https://www1.ietf.org/mailman/listinfo/midcom >> > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Mar 5 06:38:42 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 GAA27093 for ; Wed, 5 Mar 2003 06:38:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25BncG17952 for midcom-archive@odin.ietf.org; Wed, 5 Mar 2003 06:49:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Bn7517888; Wed, 5 Mar 2003 06:49:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BhM517410 for ; Wed, 5 Mar 2003 06:43:22 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26471; Wed, 5 Mar 2003 06:31:54 -0500 (EST) Message-Id: <200303051131.GAA26471@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 05 Mar 2003 06:31:54 -0500 Subject: [midcom] I-D ACTION:draft-ietf-midcom-semantics-01.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. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : MIDCOM Protocol Semantics Author(s) : M. Stiemerling et al. Filename : draft-ietf-midcom-semantics-01.txt Pages : 55 Date : 2003-3-4 This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes, such as firewalls and NATs. The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-semantics-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-semantics-01.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-3-4174400.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-semantics-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-semantics-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-4174400.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Mar 5 13:05:34 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 NAA17709 for ; Wed, 5 Mar 2003 13:05:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25IGCx03793 for midcom-archive@odin.ietf.org; Wed, 5 Mar 2003 13:16:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25IFZO03698; Wed, 5 Mar 2003 13:15:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25IDBO03478 for ; Wed, 5 Mar 2003 13:13:11 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17485 for ; Wed, 5 Mar 2003 13:02:00 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h25I44v48472 for ; Wed, 5 Mar 2003 19:04:04 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [10.1.1.128] (n-quittek.office [10.1.1.128]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 45B318AF40 for ; Wed, 5 Mar 2003 19:06:32 +0100 (CET) Date: Wed, 05 Mar 2003 19:04:24 +0100 From: Juergen Quittek To: midcom@ietf.org Message-ID: <31206572.1046891064@[10.1.1.128]> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========31224529==========" Subject: [midcom] I-D ACTION:draft-stiemerling-midcom-simco-03.txt (fwd) 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: , --==========31224529========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit Dear all, In parallel to the new version of the semantics, we submitted a new verison of our experimental SIMCO protocol that implements the updated semantics. Juergen ---------- Forwarded Message ---------- Date: 05 March 2003 06:30 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce Subject: I-D ACTION:draft-stiemerling-midcom-simco-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simple Middlebox Configuration (SIMCO) Protocol Version 2.0 Author(s) : M. Stiemerling, J. Quittek Filename : draft-stiemerling-midcom-simco-03.txt Pages : 20 Date : 2003-3-4 This memo specifies the Simple Middlebox Configuration (SIMCO) protocol for configuring Network Address Translators (NATs) and firewalls dynamically to create address bindings and open pinholes. NATs and firewalls are a problem for applications using voice and video streaming, such as IP telephony, because they need to establish voice or video channels dynamically. The SIMCO protocol allows clients to send requests for this purpose to serving NATs and/or firewalls. The protocol is designed to provide a simple and basic solution that can easily be implemented and used. The protocol meets all requirements defined by the MIDCOM working group (see [4]) and it implements the MIDCOM semantics [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-simco-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-stiemerling-midcom-simco-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-stiemerling-midcom-simco-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ---------- End Forwarded Message ---------- --==========31224529========== Content-Type: message/rfc822; name="I-D ACTION:draft-stiemerling-midcom-simco-03.txt" Return-Path: X-Sieve: cmu-sieve 2.0 Received: from yamato.ccrle.nec.de (neptune.office [10.1.1.83]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id AB0688AC5D; Wed, 5 Mar 2003 17:00:55 +0100 (CET) Received: from ran.ietf.org (ran.ietf.org [132.151.6.60]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id h25FxwE77072; Wed, 5 Mar 2003 16:59:59 +0100 (CET) Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18qa93-0008CW-00 for ietf-announce-list@ran.ietf.org; Wed, 05 Mar 2003 09:45:21 -0500 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18qZwl-0007he-01 for all-ietf@ran.ietf.org; Wed, 05 Mar 2003 09:32:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26010 for ; Wed, 5 Mar 2003 06:30:29 -0500 (EST) Message-Id: <200303051130.GAA26010@ietf.org> To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-stiemerling-midcom-simco-03.txt Date: Wed, 05 Mar 2003 06:30:28 -0500 Sender: owner-ietf-announce@ietf.org Precedence: bulk MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========31238067==========" --==========31238067========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simple Middlebox Configuration (SIMCO) Protocol Version 2.0 Author(s) : M. Stiemerling, J. Quittek Filename : draft-stiemerling-midcom-simco-03.txt Pages : 20 Date : 2003-3-4 This memo specifies the Simple Middlebox Configuration (SIMCO) protocol for configuring Network Address Translators (NATs) and firewalls dynamically to create address bindings and open pinholes. NATs and firewalls are a problem for applications using voice and video streaming, such as IP telephony, because they need to establish voice or video channels dynamically. The SIMCO protocol allows clients to send requests for this purpose to serving NATs and/or firewalls. The protocol is designed to provide a simple and basic solution that can easily be implemented and used. The protocol meets all requirements defined by the MIDCOM working group (see [4]) and it implements the MIDCOM semantics [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-simco-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-stiemerling-midcom-simco-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-stiemerling-midcom-simco-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --==========31238067========== Content-Type: multipart/alternative; boundary="==========31212654==========" --==========31212654========== Content-Type: message/external-body; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-3-4174140.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-stiemerling-midcom-simco-03.txt --==========31212654========== Content-Type: message/external-body; name="draft-stiemerling-midcom-simco-03.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-3-4174140.I-D@ietf.org> --==========31212654==========-- --==========31238067==========-- --==========31224529==========-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Mar 10 12:09:02 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 MAA03556 for ; Mon, 10 Mar 2003 12:09:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AHM6329333 for midcom-archive@odin.ietf.org; Mon, 10 Mar 2003 12:22:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHLXO29278; Mon, 10 Mar 2003 12:21:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHKIO29180 for ; Mon, 10 Mar 2003 12:20:18 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03367 for ; Mon, 10 Mar 2003 12:06:43 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2AH8n0E002264 for ; Mon, 10 Mar 2003 09:08:50 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEH50365; Mon, 10 Mar 2003 09:08:46 -0800 (PST) Message-Id: <200303101708.AEH50365@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Mon, 10 Mar 2003 12:08:45 -0500 Subject: [midcom] Semantics document 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: , You may have noticed the announcement of a revision of the semantics document. The URL is http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-01.txt. Please have a look at it, particularly section 8, and bring any discussion you may have to the mailing list. We'd like to get this document through WG last call in May. The identified open issues are: - Is IP wildcarding required? What would be application sceanrios for IP wildcarding? - Further elaborate the capability information sent from the middlebox to the agent at session setup. What further capability information should be sent? - Is there a need to support enabling ICMP, IGMP, RSVP, ...? - In case of a failure of the SE transaction because the encryption method suggested by the agent is not supported by the middlebox: Should the middlebox reply with a list of supported encryption methods? - Further elaborate section on security considerations. - Shall the agent be able to specify parameters for protection against denial of service attacks? Examples are - maximum total number of TCP connection setups allowed - maximum number of TCP connection setups per minute - maximum number of UDP packets per minute - maximum bit rate - ... Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Mar 10 19:13:41 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 TAA21740 for ; Mon, 10 Mar 2003 19:13:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2B0QsK00834 for midcom-archive@odin.ietf.org; Mon, 10 Mar 2003 19:26:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B0QRO00817; Mon, 10 Mar 2003 19:26:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B0NkO00774 for ; Mon, 10 Mar 2003 19:23:46 -0500 Received: from ctron-dnm.enterasys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21690 for ; Mon, 10 Mar 2003 19:10:03 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id TAA01522 for ; Mon, 10 Mar 2003 19:25:07 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma001513; Mon, 10 Mar 03 19:24:12 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Mon, 10 Mar 2003 19:11:57 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 10 Mar 2003 19:11:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 10 Mar 2003 19:11:44 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA489443@NHROCMBX1.ets.enterasys.com> Thread-Topic: firewall mib/ipsec policy config mib Thread-Index: AcLnYsXWAY9HdN5DRFm+A52XRzzTWg== From: "Harrington, David" To: "Midcom (E-mail)" X-OriginalArrivalTime: 11 Mar 2003 00:11:57.0614 (UTC) FILETIME=[D46734E0:01C2E762] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2B0NkO00775 Subject: [midcom] firewall mib/ipsec policy config mib 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: 8bit Hi, The IPSec Policy Configuration MIB (and related non-mib documents) are likely to advance to Proposed Standard status soon. Some of this mib's objects may apply to firewall and ACL configuration. It would be good if the WG could review the mib design and comment about its applicability in the MIDCOM environment. Note that an implementation has already been done to work with NET-SNMP. Here's the mib: ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-ipsp-ipsec-conf-mib-06.txt Thanks, dbh David Harrington Network Management Architect Office of the CTO Enterasys Networks _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Mar 11 14:16:26 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 OAA04985 for ; Tue, 11 Mar 2003 14:16:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BJU2124304 for midcom-archive@odin.ietf.org; Tue, 11 Mar 2003 14:30:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BJTUO24262; Tue, 11 Mar 2003 14:29:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BJQ8O24100 for ; Tue, 11 Mar 2003 14:26:08 -0500 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04223 for ; Tue, 11 Mar 2003 14:12:01 -0500 (EST) 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.6/8.12.6) with ESMTP id h2BJE9hs005286 for ; Tue, 11 Mar 2003 11:14:09 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEK03879; Tue, 11 Mar 2003 11:14:07 -0800 (PST) Message-Id: <200303111914.AEK03879@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Tue, 11 Mar 2003 14:14:07 -0500 Subject: [midcom] Meeting agenda 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: , I've appended the current version of the agenda for next week's meeting. Please let me know of any glaring admissions, etc. Again, we'd like to get the semantics document into WG last call as soon as it's ready, so let's try to get those open issues wrapped up. Thanks, Melinda Middlebox Communication WG (midcom) Tuesday, March 18 at 15:45-16:45 ================================ CHAIR: Melinda Shore Agenda-bashing Status update STUN Protocol evaluation midcom mib Semantics document draft-ietf-midcom-semantics-01.txt Wrap-up _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Mar 11 18:54:05 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 SAA19381 for ; Tue, 11 Mar 2003 18:54:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C07kh13792 for midcom-archive@odin.ietf.org; Tue, 11 Mar 2003 19:07:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C07DO13311; Tue, 11 Mar 2003 19:07:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C046O12874 for ; Tue, 11 Mar 2003 19:04:06 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19219 for ; Tue, 11 Mar 2003 18:49:54 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2BNq10E019217 for ; Tue, 11 Mar 2003 15:52:02 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEK46951; Tue, 11 Mar 2003 15:52:00 -0800 (PST) Message-Id: <200303112352.AEK46951@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Tue, 11 Mar 2003 18:52:00 -0500 Subject: [midcom] Semantics document in Palm DOC format 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: , Can be found at http://www.employees.org/~shore/palmdocs.html Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Mar 12 00:39:08 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 AAA27196 for ; Wed, 12 Mar 2003 00:39:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C5quk03253 for midcom-archive@odin.ietf.org; Wed, 12 Mar 2003 00:52:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C5qGO03224; Wed, 12 Mar 2003 00:52:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C5nkO03132 for ; Wed, 12 Mar 2003 00:49:46 -0500 Received: from THORONDOR.WWP.COM (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27135 for ; Wed, 12 Mar 2003 00:35:27 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 11 Mar 2003 21:37:35 -0800 Message-ID: <4E9A9436C008314EAA32033B23E96FD9187C81@thorondor.wwp.com> Thread-Topic: proposed changes for the new nat-mib draft Thread-Index: AcLoWXqm4ACROkXxTACv0SHcLrm/Mg== From: "Rohit Rohit" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2C5nkO03133 Subject: [midcom] proposed changes for the new nat-mib draft 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: 8bit Hi, Here are the list of changes, we are planning for the next version of the NAT MIB draft. 1. NAT MIB will be basically focused on TCP and UDP protocols. 2. Incorporate David's comments which include renaming of natConfAddrMapIndex to natConfAddrMapPrecedenceIndex. 3. Add a section to explain Address-map direction and BIND direction for different flavors of NAT. 4. Add description for the RowStatus objects modification. 5. Fix the threshold naming inconsistency and other typo errors. Let us know of any other comments, which should be addressed in the next version of the NAT-MIB. Thanks Rohit _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Mar 17 12:54:36 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 MAA22593 for ; Mon, 17 Mar 2003 12:54:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HIB5c20814 for midcom-archive@odin.ietf.org; Mon, 17 Mar 2003 13:11:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HIAVO20781; Mon, 17 Mar 2003 13:10:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HI7HO20312 for ; Mon, 17 Mar 2003 13:07:17 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22339 for ; Mon, 17 Mar 2003 12:50:17 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.12.8/8.12.8) with ESMTP id h2HHqTCx009318 for ; Mon, 17 Mar 2003 18:52:29 +0100 (CET) Received: from ccrle.nec.de (wl-132-217.wireless.ietf56.ietf.org [130.129.132.217]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id h2HHs64J072115 for ; Mon, 17 Mar 2003 17:54:07 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) Message-ID: <3E760B73.5060508@ccrle.nec.de> Date: Mon, 17 Mar 2003 18:52:51 +0100 From: Martin Stiemerling Organization: NEC User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Changes in the semantics I-D 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, as posted earlier on this list a new version of the MIDCOM semantics I-D is available. The major changes in this version are: - Complete reworked group behaviour: As agreed the groups are not created explicitly by the Group Establishment (GE) transaction anymore, but they are created implicit through a PER or PRR transactions type. A group is deleted after the last policy rule of this pariticular group has been deleted. There is no lifetime of a group anymore. The lifetime a group is equal to the maximum of all policy rule lifetimes. So the GE transaction is dropped, as well as the AGD notification. - reworked the draft regarding wildcarding, address and transport address in order to provide a more clear view on this topic - adapted the examples to latest changes 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 mailnull@www1.ietf.org Tue Mar 18 13:17:11 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 NAA21894 for ; Tue, 18 Mar 2003 13:17:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IIY9x04237 for midcom-archive@odin.ietf.org; Tue, 18 Mar 2003 13:34:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIXhO04211; Tue, 18 Mar 2003 13:33:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIUmO04029 for ; Tue, 18 Mar 2003 13:30:48 -0500 Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21576 for ; Tue, 18 Mar 2003 13:13:18 -0500 (EST) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.7/8.12.2) with ESMTP id h2IIFVkZ006192 for ; Tue, 18 Mar 2003 13:15:31 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.7/8.12.2/Submit) id h2IIFVmM006191 for midcom@ietf.org; Tue, 18 Mar 2003 13:15:31 -0500 (EST) Date: Tue, 18 Mar 2003 13:15:31 -0500 (EST) From: Scott Bradner Message-Id: <200303181815.h2IIFVmM006191@newdev.harvard.edu> To: midcom@ietf.org Subject: [midcom] stun 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: , its out 3489 STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs). J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy. March 2003. (Format: TXT=117562 bytes) (Status: PROPOSED STANDARD) congrats to all! Scott _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Mar 18 14:27:09 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 OAA25267 for ; Tue, 18 Mar 2003 14:27:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IJiA411303 for midcom-archive@odin.ietf.org; Tue, 18 Mar 2003 14:44:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJhVO11240; Tue, 18 Mar 2003 14:43:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJVqO09873 for ; Tue, 18 Mar 2003 14:31:52 -0500 Received: from sunserver1.ietf56.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24926 for ; Tue, 18 Mar 2003 14:14:21 -0500 (EST) Received: from sunray129.wired.ietf56.ietf.org ([130.129.64.129] helo=BPenfield) by sunserver1.ietf56.ietf.org with smtp (Exim 4.12) id 18vMZe-0000Lz-00; Tue, 18 Mar 2003 14:16:34 -0500 Message-ID: <002b01c2ed82$e18e5c90$81408182@BPenfield> From: "Bob Penfield" To: "Martin Stiemerling" , References: <3E760B73.5060508@ccrle.nec.de> Subject: [midcom] semantics does not allow agent to specify middlebox function Date: Tue, 18 Mar 2003 14:16:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 In section 2.3.6 the document states: When receiving the request, the middlebox determines how many address (and port) reservations are required based on its configuration. I believe that section 2.2.2 of RFC 3304 requires that the agent be able to indicate to the middlebox the desired function. The Midcom protocol must support the ability of an agent to install a ruleset that governs multiple types of middlebox actions (e.g. firewall and NAT). This states that a the protocol must support rules and actions for a variety of types of middleboxes. A Midcom agent ought to be able to have a single Midcom session with a middlebox and use the Midcom interface on the middlebox to interface with different middlebox functions on the same middlebox interface. This clearly states that the protocol must support a scenario where a given middlebox provides multiple functions and that the agent can specify which of those functions it wants for a given ruleset basis. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Martin Stiemerling" To: Sent: Monday, March 17, 2003 12:52 PM Subject: [midcom] Changes in the semantics I-D > Hi, > > as posted earlier on this list a new version of the MIDCOM semantics I-D > is available. The major changes in this version are: > > - Complete reworked group behaviour: > As agreed the groups are not created explicitly by the Group > Establishment (GE) transaction anymore, but they are created implicit > through a PER or PRR transactions type. A group is deleted after the > last policy rule of this pariticular group has been deleted. There is no > lifetime of a group anymore. The lifetime a group is equal to the > maximum of all policy rule lifetimes. So the GE transaction is dropped, > as well as the AGD notification. > > - reworked the draft regarding wildcarding, address and transport > address in order to provide a more clear view on this topic > > - adapted the examples to latest changes > > 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 > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Mar 18 14:30:48 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 OAA25588 for ; Tue, 18 Mar 2003 14:30:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IJlnw11822 for midcom-archive@odin.ietf.org; Tue, 18 Mar 2003 14:47:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJlRO11624; Tue, 18 Mar 2003 14:47:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJdlO11021 for ; Tue, 18 Mar 2003 14:39:47 -0500 Received: from sunserver1.ietf56.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25118 for ; Tue, 18 Mar 2003 14:22:15 -0500 (EST) Received: from sunray129.wired.ietf56.ietf.org ([130.129.64.129] helo=BPenfield) by sunserver1.ietf56.ietf.org with smtp (Exim 4.12) id 18vMhJ-0000Mr-00; Tue, 18 Mar 2003 14:24:29 -0500 Message-ID: <002f01c2ed83$fc741580$81408182@BPenfield> From: "Bob Penfield" To: "Martin Stiemerling" , References: <3E760B73.5060508@ccrle.nec.de> Date: Tue, 18 Mar 2003 14:24:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [midcom] semantics do now allow for agent failover 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 Although there is not an explicit requirement in RFC 3304, I believe that most people agree that there are scenarios where the middlebox should not delete the policy rules when the network connection to the agent is interrupted (as section 2.2.4 indicates). When there is a redundant agent and there is a failover to the redundant agent, the flows need to stay up in the middlebox. Either this should be left to the local policy/configuration of the middlebox, or there should be a request parameter in the PER or the SE that indicates whether or not policy rules are deleted in the event of interruption of the network connection with the session agent. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Mar 18 15:48:16 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 PAA29409 for ; Tue, 18 Mar 2003 15:48:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IL5JI17587 for midcom-archive@odin.ietf.org; Tue, 18 Mar 2003 16:05:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IL2GO17435; Tue, 18 Mar 2003 16:02:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IKxBO17310 for ; Tue, 18 Mar 2003 15:59:11 -0500 Received: from zcars0m9.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29243 for ; Tue, 18 Mar 2003 15:41:37 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2IKhnx10827; Tue, 18 Mar 2003 15:43:49 -0500 (EST) 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 GDF4Y5BK; Tue, 18 Mar 2003 15:43:50 -0500 Received: from nortelnetworks.com (acart455.ca.nortel.com [47.129.50.20]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G7ZYWGZH; Tue, 18 Mar 2003 15:43:49 -0500 Message-ID: <3E778504.2090509@nortelnetworks.com> Date: Tue, 18 Mar 2003 15:43:48 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Bob Penfield , midcom@ietf.org CC: Martin Stiemerling Subject: Re: [midcom] semantics do now allow for agent failover References: <3E760B73.5060508@ccrle.nec.de> <002f01c2ed83$fc741580$81408182@BPenfield> In-Reply-To: <002f01c2ed83$fc741580$81408182@BPenfield> 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 My reading of this section was that loss of the network connection implied loss of the session, not any loss of policy rules. I am a bit uneasy about this: I feel that as stated it excessively confounds the application and transport levels. I would prefer text that said: "If the protocol has been defined in such a way that loss of the network connection between the agent and the middlebox implies loss of integrity of the MIDCOM session, the session MUST be terminated when the network connection is lost." Bob Penfield wrote: > Although there is not an explicit requirement in RFC 3304, I believe that > most people agree that there are scenarios where the middlebox should not > delete the policy rules when the network connection to the agent is > interrupted (as section 2.2.4 indicates). When there is a redundant agent > and there is a failover to the redundant agent, the flows need to stay up in > the middlebox. > > Either this should be left to the local policy/configuration of the > middlebox, or there should be a request parameter in the PER or the SE that > indicates whether or not policy rules are deleted in the event of > interruption of the network connection with the session agent. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Mar 18 15:52:04 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 PAA29518 for ; Tue, 18 Mar 2003 15:52:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IL97M18561 for midcom-archive@odin.ietf.org; Tue, 18 Mar 2003 16:09:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IL59O17578; Tue, 18 Mar 2003 16:05:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IL2tO17457 for ; Tue, 18 Mar 2003 16:02:55 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29331 for ; Tue, 18 Mar 2003 15:45:21 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2IKlL706074; Tue, 18 Mar 2003 15:47:22 -0500 (EST) 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 GDFB07F7; Tue, 18 Mar 2003 15:47:22 -0500 Received: from nortelnetworks.com (acart455.ca.nortel.com [47.129.50.20]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G7ZYWGZJ; Tue, 18 Mar 2003 15:47:21 -0500 Message-ID: <3E7785D8.5000507@nortelnetworks.com> Date: Tue, 18 Mar 2003 15:47:20 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Bob Penfield CC: Martin Stiemerling , midcom@ietf.org Subject: Re: [midcom] semantics does not allow agent to specify middlebox function References: <3E760B73.5060508@ccrle.nec.de> <002b01c2ed82$e18e5c90$81408182@BPenfield> In-Reply-To: <002b01c2ed82$e18e5c90$81408182@BPenfield> 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 If this is a consensus reading of the requirements, I suspect it requires a major rewrite of the existing semantics. I think I can see justification for your interpretation, but up to now I understood the requirement to be that one should be able to tell the middlebox to 'do its thing' whatever the combination of actions that 'thing' implies. Bob Penfield wrote: > In section 2.3.6 the document states: > > When receiving the request, the middlebox determines how many > address (and port) reservations are required based on its > configuration. > > I believe that section 2.2.2 of RFC 3304 requires that the agent be able to > indicate to the middlebox the desired function. > > The Midcom protocol must support the ability of an agent to install a > ruleset that governs multiple types of middlebox actions (e.g. > firewall and NAT). > > This states that a the protocol must support rules and actions for a > variety of types of middleboxes. A Midcom agent ought to be able to > have a single Midcom session with a middlebox and use the Midcom > interface on the middlebox to interface with different middlebox > functions on the same middlebox interface. > > This clearly states that the protocol must support a scenario where a given > middlebox provides multiple functions and that the agent can specify which > of those functions it wants for a given ruleset basis. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Martin Stiemerling" > To: > Sent: Monday, March 17, 2003 12:52 PM > Subject: [midcom] Changes in the semantics I-D > > > >>Hi, >> >>as posted earlier on this list a new version of the MIDCOM semantics I-D >>is available. The major changes in this version are: >> >>- Complete reworked group behaviour: >>As agreed the groups are not created explicitly by the Group >>Establishment (GE) transaction anymore, but they are created implicit >>through a PER or PRR transactions type. A group is deleted after the >>last policy rule of this pariticular group has been deleted. There is no >>lifetime of a group anymore. The lifetime a group is equal to the >>maximum of all policy rule lifetimes. So the GE transaction is dropped, >>as well as the AGD notification. >> >>- reworked the draft regarding wildcarding, address and transport >>address in order to provide a more clear view on this topic >> >>- adapted the examples to latest changes >> >>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 >> > > > _______________________________________________ > 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 mailnull@www1.ietf.org Tue Mar 18 16:25:50 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 QAA00640 for ; Tue, 18 Mar 2003 16:25:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ILgrp21058 for midcom-archive@odin.ietf.org; Tue, 18 Mar 2003 16:42:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ILgLO20998; Tue, 18 Mar 2003 16:42:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ILdmO20852 for ; Tue, 18 Mar 2003 16:39:48 -0500 Received: from sunserver1.ietf56.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00571 for ; Tue, 18 Mar 2003 16:22:13 -0500 (EST) Received: from wl-134-136.wireless.ietf56.ietf.org ([130.129.134.136] helo=quittek.office) by sunserver1.ietf56.ietf.org with esmtp (Exim 4.12) id 18vOZO-0000YF-00; Tue, 18 Mar 2003 16:24:26 -0500 Date: Tue, 18 Mar 2003 22:25:02 +0100 From: Juergen Quittek To: Bob Penfield , Martin Stiemerling , midcom@ietf.org Subject: Re: [midcom] semantics does not allow agent to specify middlebox function Message-ID: <33037685.1048026301@quittek.office> In-Reply-To: <002b01c2ed82$e18e5c90$81408182@BPenfield> References: <002b01c2ed82$e18e5c90$81408182@BPenfield> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit 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 Bob, Thanks a lot for reviewing the semantics! -- Bob Penfield wrote on 18 March 2003 14:16 -0500: > In section 2.3.6 the document states: > > When receiving the request, the middlebox determines how many > address (and port) reservations are required based on its > configuration. > > I believe that section 2.2.2 of RFC 3304 requires that the agent be able to > indicate to the middlebox the desired function. > > The Midcom protocol must support the ability of an agent to install a > ruleset that governs multiple types of middlebox actions (e.g. > firewall and NAT). > > This states that a the protocol must support rules and actions for a > variety of types of middleboxes. A Midcom agent ought to be able to > have a single Midcom session with a middlebox and use the Midcom > interface on the middlebox to interface with different middlebox > functions on the same middlebox interface. > > This clearly states that the protocol must support a scenario where a given > middlebox provides multiple functions and that the agent can specify which > of those functions it wants for a given ruleset basis. That's an interesting comment that probably will end up in some clarifications added to the semantics. We (at least intend to) realize section 2.2.2 of RFC 3304 by having just an "enable" policy action telling the middlebox: Whatever you need to do for realizing this, please do so. This includes all required pinhole creations and binding establishments, inependent of the type of middlebox. In general, the agent should be able to communicate with the middlebox without considering what kind of box it is talking to. The phrase you cited > In section 2.3.6 the document states: > > When receiving the request, the middlebox determines how many > address (and port) reservations are required based on its > configuration. is probably misleading as it is written now. It just replects that - a firewall does not need to perform any reservation - a traditonal NAT only needs to perform reservations on the external side - a twice-NAT needs to perform reservations on the external side as well as on the internal side. The middlebox then returns the reservations made. I think that this completely meets the the requirement stated in section 2.2.2 of RFC 3304. Cheers, Juergen > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Martin Stiemerling" > To: > Sent: Monday, March 17, 2003 12:52 PM > Subject: [midcom] Changes in the semantics I-D > > >> Hi, >> >> as posted earlier on this list a new version of the MIDCOM semantics I-D >> is available. The major changes in this version are: >> >> - Complete reworked group behaviour: >> As agreed the groups are not created explicitly by the Group >> Establishment (GE) transaction anymore, but they are created implicit >> through a PER or PRR transactions type. A group is deleted after the >> last policy rule of this pariticular group has been deleted. There is no >> lifetime of a group anymore. The lifetime a group is equal to the >> maximum of all policy rule lifetimes. So the GE transaction is dropped, >> as well as the AGD notification. >> >> - reworked the draft regarding wildcarding, address and transport >> address in order to provide a more clear view on this topic >> >> - adapted the examples to latest changes >> >> 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 >> > > _______________________________________________ > 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 mailnull@www1.ietf.org Tue Mar 18 16:31:30 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 QAA01043 for ; Tue, 18 Mar 2003 16:31:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ILmYq21535 for midcom-archive@odin.ietf.org; Tue, 18 Mar 2003 16:48:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ILm8O21488; Tue, 18 Mar 2003 16:48:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ILjtO21296 for ; Tue, 18 Mar 2003 16:45:55 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00772 for ; Tue, 18 Mar 2003 16:28:20 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.12.8/8.12.8) with ESMTP id h2ILUXCx012638; Tue, 18 Mar 2003 22:30:33 +0100 (CET) Received: from ccrle.nec.de (wl-132-217.wireless.ietf56.ietf.org [130.129.132.217]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id h2ILWB4J078177; Tue, 18 Mar 2003 21:32:12 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) Message-ID: <3E778FE6.5050606@ccrle.nec.de> Date: Tue, 18 Mar 2003 22:30:14 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Penfield CC: midcom@ietf.org Subject: Re: [midcom] semantics does not allow agent to specify middlebox function References: <3E760B73.5060508@ccrle.nec.de> <002b01c2ed82$e18e5c90$81408182@BPenfield> 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 Hi Bob, thanks for reading the draft and your comments! Please find my comments inline. Martin Bob Penfield wrote: > In section 2.3.6 the document states: > > When receiving the request, the middlebox determines how many > address (and port) reservations are required based on its > configuration. > > I believe that section 2.2.2 of RFC 3304 requires that the agent be able to > indicate to the middlebox the desired function. > > The Midcom protocol must support the ability of an agent to install a > ruleset that governs multiple types of middlebox actions (e.g. > firewall and NAT). The semantics support meet this requirement fully. Since the agent is able to install policy rulesets that govern multiple types of middlebox actions. The policy rules given by the middlebox agent to the middlebox may splitted internally in the middlebox to multiple actions, like packetfilter-NAT-packetfilter or only NAT-packetfilter (please read this as the combination of packetfilters and NATs). So the policy rule may comprise two packetfilter actions and a NAT mapping. If you assume that the agent should be able to indicate the action, the agent must be aware about the actuall configuration of the middlebox, whereas configuration is meant as: Where are the packet filters and NATs in the datagram flow. > > This states that a the protocol must support rules and actions for a > variety of types of middleboxes. A Midcom agent ought to be able to > have a single Midcom session with a middlebox and use the Midcom > interface on the middlebox to interface with different middlebox > functions on the same middlebox interface. > > This clearly states that the protocol must support a scenario where a given > middlebox provides multiple functions and that the agent can specify which > of those functions it wants for a given ruleset basis. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Martin Stiemerling" > To: > Sent: Monday, March 17, 2003 12:52 PM > Subject: [midcom] Changes in the semantics I-D > > > >>Hi, >> >>as posted earlier on this list a new version of the MIDCOM semantics I-D >>is available. The major changes in this version are: >> >>- Complete reworked group behaviour: >>As agreed the groups are not created explicitly by the Group >>Establishment (GE) transaction anymore, but they are created implicit >>through a PER or PRR transactions type. A group is deleted after the >>last policy rule of this pariticular group has been deleted. There is no >>lifetime of a group anymore. The lifetime a group is equal to the >>maximum of all policy rule lifetimes. So the GE transaction is dropped, >>as well as the AGD notification. >> >>- reworked the draft regarding wildcarding, address and transport >>address in order to provide a more clear view on this topic >> >>- adapted the examples to latest changes >> >>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 >> > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Mar 18 16:34:25 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 QAA01243 for ; Tue, 18 Mar 2003 16:34:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ILpSB21707 for midcom-archive@odin.ietf.org; Tue, 18 Mar 2003 16:51:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ILp4O21661; Tue, 18 Mar 2003 16:51:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ILkfO21351 for ; Tue, 18 Mar 2003 16:46:41 -0500 Received: from sunserver1.ietf56.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00802 for ; Tue, 18 Mar 2003 16:29:07 -0500 (EST) Received: from wl-134-136.wireless.ietf56.ietf.org ([130.129.134.136] helo=quittek.office) by sunserver1.ietf56.ietf.org with esmtp (Exim 4.12) id 18vOg4-0000Z6-00; Tue, 18 Mar 2003 16:31:20 -0500 Date: Tue, 18 Mar 2003 22:31:55 +0100 From: Juergen Quittek To: Bob Penfield , Martin Stiemerling , midcom@ietf.org Subject: Re: [midcom] semantics do now allow for agent failover Message-ID: <33450789.1048026714@quittek.office> In-Reply-To: <002f01c2ed83$fc741580$81408182@BPenfield> References: <002f01c2ed83$fc741580$81408182@BPenfield> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit 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 Bob, -- Bob Penfield wrote on 18 March 2003 14:24 -0500: > Although there is not an explicit requirement in RFC 3304, I believe that > most people agree that there are scenarios where the middlebox should not > delete the policy rules when the network connection to the agent is > interrupted (as section 2.2.4 indicates). When there is a redundant agent This seems to be a misunderstanding. Section 2.2.4 states "same [effect] as for the Asynchronous Session Terminaltion. In section 2.2.3 on Asynchronous Session Terminaltion it is started that After session terminationthe middlebox keeps all established policy rules until thier lifetime expires or until an event occurs on which the middlebox terminates them. So no policy rules are deleted on session interruption by the network. Cheers, Juergen > and there is a failover to the redundant agent, the flows need to stay up in > the middlebox. > > Either this should be left to the local policy/configuration of the > middlebox, or there should be a request parameter in the PER or the SE that > indicates whether or not policy rules are deleted in the event of > interruption of the network connection with the session agent. > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Mar 18 16:40:45 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 QAA01482 for ; Tue, 18 Mar 2003 16:40:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ILvnO22050 for midcom-archive@odin.ietf.org; Tue, 18 Mar 2003 16:57:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ILv9O22025; Tue, 18 Mar 2003 16:57:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ILsgO21880 for ; Tue, 18 Mar 2003 16:54:42 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01424 for ; Tue, 18 Mar 2003 16:37:07 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.12.8/8.12.8) with ESMTP id h2ILdKCx013655; Tue, 18 Mar 2003 22:39:20 +0100 (CET) Received: from ccrle.nec.de (wl-132-217.wireless.ietf56.ietf.org [130.129.132.217]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id h2ILex4J078215; Tue, 18 Mar 2003 21:40:59 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) Message-ID: <3E7791E2.5070209@ccrle.nec.de> Date: Tue, 18 Mar 2003 22:38:42 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Penfield CC: midcom@ietf.org References: <3E760B73.5060508@ccrle.nec.de> <002f01c2ed83$fc741580$81408182@BPenfield> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Re: semantics do now allow for agent failover 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 Bob Penfield wrote: > Although there is not an explicit requirement in RFC 3304, I believe that > most people agree that there are scenarios where the middlebox should not > delete the policy rules when the network connection to the agent is > interrupted (as section 2.2.4 indicates). When there is a redundant agent > and there is a failover to the redundant agent, the flows need to stay up in > the middlebox. I agree that a loss in network connection should not result in deleting all corresponding policy rules (nice DOS attack :). The semantics say in 2.2.4 that the effect on network connection loss is the same as in 2.2.3 AST. This section says in the last sentence: "After session termination the middlebox keeps all established policy rules until their lifetime expires or until an event occurs on which the middlebox terminates them." So the middlebox keeps the policy rules until their lifetime expires. Do you think that this behaviour is OK? So a failover agent could take over the rules as long as the policy rules do not timeout. > > Either this should be left to the local policy/configuration of the > middlebox, or there should be a request parameter in the PER or the SE that > indicates whether or not policy rules are deleted in the event of > interruption of the network connection with the session agent. Good question. I would propose to append to the above statement something like "depending on local configuration". Thanks again for reading it :) Cheers Martin > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Mar 18 17:35:39 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 RAA03242 for ; Tue, 18 Mar 2003 17:35:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IMqj326719 for midcom-archive@odin.ietf.org; Tue, 18 Mar 2003 17:52:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IMqDO26701; Tue, 18 Mar 2003 17:52:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IMnZO26587 for ; Tue, 18 Mar 2003 17:49:35 -0500 Received: from sunserver1.ietf56.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03159 for ; Tue, 18 Mar 2003 17:31:58 -0500 (EST) Received: from sunray129.wired.ietf56.ietf.org ([130.129.64.129] helo=BPenfield) by sunserver1.ietf56.ietf.org with smtp (Exim 4.12) id 18vPeu-0000el-00; Tue, 18 Mar 2003 17:34:12 -0500 Message-ID: <002701c2ed9e$7d7328f0$81408182@BPenfield> From: "Bob Penfield" To: "Juergen Quittek" , "Martin Stiemerling" , References: <002b01c2ed82$e18e5c90$81408182@BPenfield> <33037685.1048026301@quittek.office> Subject: Re: [midcom] semantics does not allow agent to specify middlebox function Date: Tue, 18 Mar 2003 17:34:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 My point was that if the agent is talking to a middlebox that can do both NAPT and Twice-NAT, and the agent wants one or the other, it should be able to tell the middlebox which type it wants. The primary motivation for the original requirement was to be able to obtain a NAT binding and open the firewall pin-hole in a single transaction as opposed to two separate transaction and the semantics reflect that. I have always believed that this requirement meant that the agent could indicate which function or functions it wanted that the middlebox provided. For example, with a middlebox that provides traditional NAT functionality (i.e. NAPT on packets it sees rather than at the request of an agent) may have Twice-NAT capability and a VOIP midcom agent wants both an inside and an outside address when enabling an RTP flow. Why do we need to restrict the agent to one type of middlebox function? ----- Original Message ----- From: "Juergen Quittek" To: "Bob Penfield" ; "Martin Stiemerling" ; Sent: Tuesday, March 18, 2003 4:25 PM Subject: Re: [midcom] semantics does not allow agent to specify middlebox function > Hi Bob, > > Thanks a lot for reviewing the semantics! > > -- Bob Penfield wrote on 18 March 2003 14:16 -0500: > > > In section 2.3.6 the document states: > > > > When receiving the request, the middlebox determines how many > > address (and port) reservations are required based on its > > configuration. > > > > I believe that section 2.2.2 of RFC 3304 requires that the agent be able to > > indicate to the middlebox the desired function. > > > > The Midcom protocol must support the ability of an agent to install a > > ruleset that governs multiple types of middlebox actions (e.g. > > firewall and NAT). > > > > This states that a the protocol must support rules and actions for a > > variety of types of middleboxes. A Midcom agent ought to be able to > > have a single Midcom session with a middlebox and use the Midcom > > interface on the middlebox to interface with different middlebox > > functions on the same middlebox interface. > > > > This clearly states that the protocol must support a scenario where a given > > middlebox provides multiple functions and that the agent can specify which > > of those functions it wants for a given ruleset basis. > > That's an interesting comment that probably will end up in some clarifications > added to the semantics. > > We (at least intend to) realize section 2.2.2 of RFC 3304 by having just an > "enable" policy action telling the middlebox: Whatever you need to do for realizing > this, please do so. This includes all required pinhole creations and binding > establishments, inependent of the type of middlebox. In general, the agent should > be able to communicate with the middlebox without considering what kind of box > it is talking to. > > The phrase you cited > > > In section 2.3.6 the document states: > > > > When receiving the request, the middlebox determines how many > > address (and port) reservations are required based on its > > configuration. > > is probably misleading as it is written now. It just replects that > - a firewall does not need to perform any reservation > - a traditonal NAT only needs to perform reservations on the external > side > - a twice-NAT needs to perform reservations on the external side as > well as on the internal side. > > The middlebox then returns the reservations made. > > I think that this completely meets the the requirement stated in > section 2.2.2 of RFC 3304. > > Cheers, > > Juergen > > > cheers, > > (-:bob > > > > Robert F. Penfield > > Chief Software Architect > > Acme Packet, Inc. > > 130 New Boston Street > > Woburn, MA 01801 > > bpenfield@acmepacket.com > > > > ----- Original Message ----- > > From: "Martin Stiemerling" > > To: > > Sent: Monday, March 17, 2003 12:52 PM > > Subject: [midcom] Changes in the semantics I-D > > > > > >> Hi, > >> > >> as posted earlier on this list a new version of the MIDCOM semantics I-D > >> is available. The major changes in this version are: > >> > >> - Complete reworked group behaviour: > >> As agreed the groups are not created explicitly by the Group > >> Establishment (GE) transaction anymore, but they are created implicit > >> through a PER or PRR transactions type. A group is deleted after the > >> last policy rule of this pariticular group has been deleted. There is no > >> lifetime of a group anymore. The lifetime a group is equal to the > >> maximum of all policy rule lifetimes. So the GE transaction is dropped, > >> as well as the AGD notification. > >> > >> - reworked the draft regarding wildcarding, address and transport > >> address in order to provide a more clear view on this topic > >> > >> - adapted the examples to latest changes > >> > >> 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 > >> > > > > _______________________________________________ > > 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 mailnull@www1.ietf.org Tue Mar 18 17:42:11 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 RAA03390 for ; Tue, 18 Mar 2003 17:42:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IMxHL27089 for midcom-archive@odin.ietf.org; Tue, 18 Mar 2003 17:59:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IMw5O27007; Tue, 18 Mar 2003 17:58:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IMsHO26847 for ; Tue, 18 Mar 2003 17:54:17 -0500 Received: from sunserver1.ietf56.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03266 for ; Tue, 18 Mar 2003 17:36:40 -0500 (EST) Received: from sunray129.wired.ietf56.ietf.org ([130.129.64.129] helo=BPenfield) by sunserver1.ietf56.ietf.org with smtp (Exim 4.12) id 18vPjT-0000fW-00; Tue, 18 Mar 2003 17:38:55 -0500 Message-ID: <003901c2ed9f$25a860d0$81408182@BPenfield> From: "Bob Penfield" To: "Juergen Quittek" , "Martin Stiemerling" , References: <002f01c2ed83$fc741580$81408182@BPenfield> <33450789.1048026714@quittek.office> Subject: Re: [midcom] semantics do now allow for agent failover Date: Tue, 18 Mar 2003 17:38:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 sorry, my mistake. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Juergen Quittek" To: "Bob Penfield" ; "Martin Stiemerling" ; Sent: Tuesday, March 18, 2003 4:31 PM Subject: Re: [midcom] semantics do now allow for agent failover > Bob, > > -- Bob Penfield wrote on 18 March 2003 14:24 -0500: > > > Although there is not an explicit requirement in RFC 3304, I believe that > > most people agree that there are scenarios where the middlebox should not > > delete the policy rules when the network connection to the agent is > > interrupted (as section 2.2.4 indicates). When there is a redundant agent > > This seems to be a misunderstanding. Section 2.2.4 states "same [effect] as > for the Asynchronous Session Terminaltion. In section 2.2.3 on Asynchronous > Session Terminaltion it is started that > > After session terminationthe middlebox keeps all established > policy rules until thier lifetime expires or until an event occurs > on which the middlebox terminates them. > > So no policy rules are deleted on session interruption by the network. > > Cheers, > > Juergen > > > > and there is a failover to the redundant agent, the flows need to stay up in > > the middlebox. > > > > Either this should be left to the local policy/configuration of the > > middlebox, or there should be a request parameter in the PER or the SE that > > indicates whether or not policy rules are deleted in the event of > > interruption of the network connection with the session agent. > > > > cheers, > > (-:bob > > > > Robert F. Penfield > > Chief Software Architect > > Acme Packet, Inc. > > 130 New Boston Street > > Woburn, MA 01801 > > bpenfield@acmepacket.com > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Mar 18 17:42:34 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 RAA03406 for ; Tue, 18 Mar 2003 17:42:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IMxd727106 for midcom-archive@odin.ietf.org; Tue, 18 Mar 2003 17:59:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IMtIO26884; Tue, 18 Mar 2003 17:55:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IMphO26686 for ; Tue, 18 Mar 2003 17:51:43 -0500 Received: from sunserver1.ietf56.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03203 for ; Tue, 18 Mar 2003 17:34:06 -0500 (EST) Received: from sunray129.wired.ietf56.ietf.org ([130.129.64.129] helo=BPenfield) by sunserver1.ietf56.ietf.org with smtp (Exim 4.12) id 18vPgy-0000fN-00; Tue, 18 Mar 2003 17:36:20 -0500 Message-ID: <003301c2ed9e$c9bbf7f0$81408182@BPenfield> From: "Bob Penfield" To: "Martin Stiemerling" Cc: References: <3E760B73.5060508@ccrle.nec.de> <002b01c2ed82$e18e5c90$81408182@BPenfield> <3E778FE6.5050606@ccrle.nec.de> Subject: Re: [midcom] semantics does not allow agent to specify middlebox function Date: Tue, 18 Mar 2003 17:36:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 see inline ----- Original Message ----- From: "Martin Stiemerling" > Martin > > Bob Penfield wrote: > > In section 2.3.6 the document states: > > > > When receiving the request, the middlebox determines how many > > address (and port) reservations are required based on its > > configuration. > > > > I believe that section 2.2.2 of RFC 3304 requires that the agent be able to > > indicate to the middlebox the desired function. > > > > The Midcom protocol must support the ability of an agent to install a > > ruleset that governs multiple types of middlebox actions (e.g. > > firewall and NAT). > > The semantics support meet this requirement fully. Since the agent is > able to install policy rulesets that govern multiple types of middlebox > actions. The policy rules given by the middlebox agent to the middlebox > may splitted internally in the middlebox to multiple actions, like > packetfilter-NAT-packetfilter or only NAT-packetfilter (please read this > as the combination of packetfilters and NATs). So the policy rule may > comprise two packetfilter actions and a NAT mapping. If you assume that > the agent should be able to indicate the action, the agent must be aware > about the actuall configuration of the middlebox, whereas configuration > is meant as: Where are the packet filters and NATs in the datagram flow. > If the middlebox is capable of both NAPT and Twice-NAT, how does the middlebox know which one the agent wants? > > > > This states that a the protocol must support rules and actions for a > > variety of types of middleboxes. A Midcom agent ought to be able to > > have a single Midcom session with a middlebox and use the Midcom > > interface on the middlebox to interface with different middlebox > > functions on the same middlebox interface. > > > > This clearly states that the protocol must support a scenario where a given > > middlebox provides multiple functions and that the agent can specify which > > of those functions it wants for a given ruleset basis. > > > > > > cheers, > > (-:bob > > > > Robert F. Penfield > > Chief Software Architect > > Acme Packet, Inc. > > 130 New Boston Street > > Woburn, MA 01801 > > bpenfield@acmepacket.com > > > > ----- Original Message ----- > > From: "Martin Stiemerling" > > To: > > Sent: Monday, March 17, 2003 12:52 PM > > Subject: [midcom] Changes in the semantics I-D > > > > > > > >>Hi, > >> > >>as posted earlier on this list a new version of the MIDCOM semantics I-D > >>is available. The major changes in this version are: > >> > >>- Complete reworked group behaviour: > >>As agreed the groups are not created explicitly by the Group > >>Establishment (GE) transaction anymore, but they are created implicit > >>through a PER or PRR transactions type. A group is deleted after the > >>last policy rule of this pariticular group has been deleted. There is no > >>lifetime of a group anymore. The lifetime a group is equal to the > >>maximum of all policy rule lifetimes. So the GE transaction is dropped, > >>as well as the AGD notification. > >> > >>- reworked the draft regarding wildcarding, address and transport > >>address in order to provide a more clear view on this topic > >> > >>- adapted the examples to latest changes > >> > >>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 > >> > > > > > > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Mar 18 17:52:37 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 RAA03682 for ; Tue, 18 Mar 2003 17:52:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IN9fi28364 for midcom-archive@odin.ietf.org; Tue, 18 Mar 2003 18:09:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IN97O28344; Tue, 18 Mar 2003 18:09:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IN6qO27495 for ; Tue, 18 Mar 2003 18:06:52 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03579 for ; Tue, 18 Mar 2003 17:49:15 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.12.8/8.12.8) with ESMTP id h2IMpSCx016654; Tue, 18 Mar 2003 23:51:28 +0100 (CET) Received: from ccrle.nec.de (wl-132-45.wireless.ietf56.ietf.org [130.129.132.45]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id h2IMr74J078468; Tue, 18 Mar 2003 22:53:08 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) Message-ID: <3E77A306.5020108@ccrle.nec.de> Date: Tue, 18 Mar 2003 23:51:50 +0100 From: Martin Stiemerling Organization: NEC User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Penfield CC: midcom@ietf.org Subject: Re: [midcom] semantics does not allow agent to specify middlebox function References: <3E760B73.5060508@ccrle.nec.de> <002b01c2ed82$e18e5c90$81408182@BPenfield> <3E778FE6.5050606@ccrle.nec.de> <003301c2ed9e$c9bbf7f0$81408182@BPenfield> 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 A basic question of understanding (inline): Bob Penfield wrote: > > > If the middlebox is capable of both NAPT and Twice-NAT, how does the > middlebox know which one the agent wants? Are there middleboxes out there in operation that can do either NAPT or twice-NAT and switch instantly? With NAPT you mean Network Address and Port Translation, right? Martin > > >>> This states that a the protocol must support rules and actions for a _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Mar 18 19:26:58 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 TAA07951 for ; Tue, 18 Mar 2003 19:26:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J0i5901837 for midcom-archive@odin.ietf.org; Tue, 18 Mar 2003 19:44:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J0hQO01711; Tue, 18 Mar 2003 19:43:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J0eXO01607 for ; Tue, 18 Mar 2003 19:40:33 -0500 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07793 for ; Tue, 18 Mar 2003 19:22:55 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2J0Owhs008936; Tue, 18 Mar 2003 16:24:58 -0800 (PST) Received: from cscoamera10416 (dhcp-171-71-73-38.cisco.com [171.71.73.38]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AFG36438; Tue, 18 Mar 2003 16:23:43 -0800 (PST) Reply-To: From: "Adina Simu \(asimu\)" To: "'Martin Stiemerling'" , "'Bob Penfield'" Cc: Subject: RE: [midcom] semantics does not allow agent to specify middleboxfunction Date: Tue, 18 Mar 2003 16:24:57 -0800 Message-ID: <005401c2edad$f88bc5b0$264947ab@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3E77A306.5020108@ccrle.nec.de> Importance: Normal 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 There are middleboxes which can do both -- based on criteria like one of the addresses, both addresses, direction of traffic, etc. one or both types of translations are used. -Adina > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On > Behalf Of Martin Stiemerling > Sent: Tuesday, March 18, 2003 2:52 PM > To: Bob Penfield > Cc: midcom@ietf.org > Subject: Re: [midcom] semantics does not allow agent to > specify middleboxfunction > > > A basic question of understanding (inline): > > Bob Penfield wrote: > > > > > > If the middlebox is capable of both NAPT and Twice-NAT, how > does the > > middlebox know which one the agent wants? > > Are there middleboxes out there in operation that can do > either NAPT or > twice-NAT and switch instantly? > With NAPT you mean Network Address and Port Translation, right? > > Martin > > > > > > >>> This states that a the protocol must support rules and > actions for > >>> a > > _______________________________________________ > 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 mailnull@www1.ietf.org Tue Mar 18 19:32:25 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 TAA08424 for ; Tue, 18 Mar 2003 19:32:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J0nVb02250 for midcom-archive@odin.ietf.org; Tue, 18 Mar 2003 19:49:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J0n6O02188; Tue, 18 Mar 2003 19:49:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J0kRO01935 for ; Tue, 18 Mar 2003 19:46:27 -0500 Received: from sunserver1.ietf56.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08024 for ; Tue, 18 Mar 2003 19:28:49 -0500 (EST) Received: from wl-134-136.wireless.ietf56.ietf.org ([130.129.134.136] helo=quittek.office) by sunserver1.ietf56.ietf.org with esmtp (Exim 4.12) id 18vRTx-0000qE-00; Tue, 18 Mar 2003 19:31:01 -0500 Date: Wed, 19 Mar 2003 01:31:38 +0100 From: Juergen Quittek To: Bob Penfield , Martin Stiemerling , midcom@ietf.org Subject: Re: [midcom] semantics does not allow agent to specify middlebox function Message-ID: <44233634.1048037497@quittek.office> In-Reply-To: <002701c2ed9e$7d7328f0$81408182@BPenfield> References: <002701c2ed9e$7d7328f0$81408182@BPenfield> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit 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 Bob, -- Bob Penfield wrote on 18 March 2003 17:34 -0500: > > My point was that if the agent is talking to a middlebox that can do both > NAPT and Twice-NAT, and the agent wants one or the other, it should be able > to tell the middlebox which type it wants. The PRR request message contains a parameter (transport protocol) indicating whether a NAT or NAPT service is requested by the agent. This is (hopefully in a clear way) explained in the new section 2.3.5. So - at least for your example - the agent can chose between the NAPT and the twice-NAT. I would not exclude the possibility that there are scenarios that are not supported by our semantics, but so far, we did not find any. Further input on this is very welcome. Cheers, Juergen > The primary motivation for the original requirement was to be able to obtain > a NAT binding and open the firewall pin-hole in a single transaction as > opposed to two separate transaction and the semantics reflect that. > > I have always believed that this requirement meant that the agent could > indicate which function or functions it wanted that the middlebox provided. > > For example, with a middlebox that provides traditional NAT functionality > (i.e. NAPT on packets it sees rather than at the request of an agent) may > have Twice-NAT capability and a VOIP midcom agent wants both an inside and > an outside address when enabling an RTP flow. > > Why do we need to restrict the agent to one type of middlebox function? > > ----- Original Message ----- > From: "Juergen Quittek" > To: "Bob Penfield" ; "Martin Stiemerling" > ; > Sent: Tuesday, March 18, 2003 4:25 PM > Subject: Re: [midcom] semantics does not allow agent to specify middlebox > function > > >> Hi Bob, >> >> Thanks a lot for reviewing the semantics! >> >> -- Bob Penfield wrote on 18 March 2003 14:16 -0500: >> >> > In section 2.3.6 the document states: >> > >> > When receiving the request, the middlebox determines how many >> > address (and port) reservations are required based on its >> > configuration. >> > >> > I believe that section 2.2.2 of RFC 3304 requires that the agent be able > to >> > indicate to the middlebox the desired function. >> > >> > The Midcom protocol must support the ability of an agent to install a >> > ruleset that governs multiple types of middlebox actions (e.g. >> > firewall and NAT). >> > >> > This states that a the protocol must support rules and actions for a >> > variety of types of middleboxes. A Midcom agent ought to be able to >> > have a single Midcom session with a middlebox and use the Midcom >> > interface on the middlebox to interface with different middlebox >> > functions on the same middlebox interface. >> > >> > This clearly states that the protocol must support a scenario where a > given >> > middlebox provides multiple functions and that the agent can specify > which >> > of those functions it wants for a given ruleset basis. >> >> That's an interesting comment that probably will end up in some > clarifications >> added to the semantics. >> >> We (at least intend to) realize section 2.2.2 of RFC 3304 by having just > an >> "enable" policy action telling the middlebox: Whatever you need to do for > realizing >> this, please do so. This includes all required pinhole creations and > binding >> establishments, inependent of the type of middlebox. In general, the agent > should >> be able to communicate with the middlebox without considering what kind of > box >> it is talking to. >> >> The phrase you cited >> >> > In section 2.3.6 the document states: >> > >> > When receiving the request, the middlebox determines how many >> > address (and port) reservations are required based on its >> > configuration. >> >> is probably misleading as it is written now. It just replects that >> - a firewall does not need to perform any reservation >> - a traditonal NAT only needs to perform reservations on the external >> side >> - a twice-NAT needs to perform reservations on the external side as >> well as on the internal side. >> >> The middlebox then returns the reservations made. >> >> I think that this completely meets the the requirement stated in >> section 2.2.2 of RFC 3304. >> >> Cheers, >> >> Juergen >> >> > cheers, >> > (-:bob >> > >> > Robert F. Penfield >> > Chief Software Architect >> > Acme Packet, Inc. >> > 130 New Boston Street >> > Woburn, MA 01801 >> > bpenfield@acmepacket.com >> > >> > ----- Original Message ----- >> > From: "Martin Stiemerling" >> > To: >> > Sent: Monday, March 17, 2003 12:52 PM >> > Subject: [midcom] Changes in the semantics I-D >> > >> > >> >> Hi, >> >> >> >> as posted earlier on this list a new version of the MIDCOM semantics > I-D >> >> is available. The major changes in this version are: >> >> >> >> - Complete reworked group behaviour: >> >> As agreed the groups are not created explicitly by the Group >> >> Establishment (GE) transaction anymore, but they are created implicit >> >> through a PER or PRR transactions type. A group is deleted after the >> >> last policy rule of this pariticular group has been deleted. There is > no >> >> lifetime of a group anymore. The lifetime a group is equal to the >> >> maximum of all policy rule lifetimes. So the GE transaction is dropped, >> >> as well as the AGD notification. >> >> >> >> - reworked the draft regarding wildcarding, address and transport >> >> address in order to provide a more clear view on this topic >> >> >> >> - adapted the examples to latest changes >> >> >> >> 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 >> >> >> > >> > _______________________________________________ >> > 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 mailnull@www1.ietf.org Tue Mar 18 20:09:18 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 UAA10419 for ; Tue, 18 Mar 2003 20:09:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J1QPs05182 for midcom-archive@odin.ietf.org; Tue, 18 Mar 2003 20:26:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J1PDO05130; Tue, 18 Mar 2003 20:25:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J1M3O04980 for ; Tue, 18 Mar 2003 20:22:03 -0500 Received: from NREXCH.netrake.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10137 for ; Tue, 18 Mar 2003 20:04:25 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Tue, 18 Mar 2003 19:07:25 -0600 Message-ID: <7E06D3212981524CA10D2A114937C41401357218@nrexch.netrake.net> Thread-Topic: IP wildcard scenarios Thread-Index: AcLts+dp9DCtExAHTDOXltbr2lBk/w== From: "Jasson Casey" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h2J1M3O04981 Subject: [midcom] IP wildcard scenarios 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: 8bit I've noticed several things that would require IP wildcarding. * Early Media The middlebox must be prepared to forward inbound media that can be sent in response to the sdp c and m. At this point no one knows the source IP/port of these inbound media packets. * pstn gateways SDP M/C lines are only indication of where audio will be reiceved. There are several gateways that send on one ip/port pair while recieving (indicated through sdp) on a different pair. * certain advanced scenarios ie. audio anouncements During a prepaid application there is a good chance that the "You have 30 seconds left, please pay more money" (anouncement server) message does not come from either endpoint were the participants would be located. The src ip/port of the anouncement server is never indicated anywhere in the dialog signaling. * Symetric Relationship I seems dangerous to assume a symetric relationship ever exists between the indicated ip/port(s) of SDP in any dialog. I thought someone suggested that the rules could be established over the duration of a session, The idea being a middlebox would have * in the src ip/port during the initial signaling sequences, but then a ip/port would be learned and applied. This seems like a bad idea because of anouncements, and other scenarios that exhibit this behavior (i don't think this behavior can be limited under the current standards). My thoughts at least. Jasson Casey jasson@netrake.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Mar 18 21:29: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 VAA12451 for ; Tue, 18 Mar 2003 21:29:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J2kjh10615 for midcom-archive@odin.ietf.org; Tue, 18 Mar 2003 21:46:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J2k9O10577; Tue, 18 Mar 2003 21:46:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J2h3O10440 for ; Tue, 18 Mar 2003 21:43:03 -0500 Received: from sunserver1.ietf56.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12370 for ; Tue, 18 Mar 2003 21:25:23 -0500 (EST) Received: from sunray129.wired.ietf56.ietf.org ([130.129.64.129] helo=BPenfield) by sunserver1.ietf56.ietf.org with smtp (Exim 4.12) id 18vTIl-00011F-00; Tue, 18 Mar 2003 21:27:35 -0500 Message-ID: <001d01c2edbf$18e284f0$81408182@BPenfield> From: "Bob Penfield" To: "Martin Stiemerling" Cc: References: <3E760B73.5060508@ccrle.nec.de> <002b01c2ed82$e18e5c90$81408182@BPenfield> <3E778FE6.5050606@ccrle.nec.de> <003301c2ed9e$c9bbf7f0$81408182@BPenfield> <3E77A306.5020108@ccrle.nec.de> Subject: Re: [midcom] semantics does not allow agent to specify middlebox function Date: Tue, 18 Mar 2003 21:27:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 ----- Original Message ----- From: "Martin Stiemerling" > A basic question of understanding (inline): > > Bob Penfield wrote: > > > > If the middlebox is capable of both NAPT and Twice-NAT, how does the > > middlebox know which one the agent wants? > > Are there middleboxes out there in operation that can do either NAPT or > twice-NAT and switch instantly? > With NAPT you mean Network Address and Port Translation, right? > > Martin > I know of at least one box that is capable of NAPT and Twice-NAT (actually twice-NAPT) on a rule-by-rule basis. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Mar 18 21:37:27 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 VAA12668 for ; Tue, 18 Mar 2003 21:37:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J2sap10916 for midcom-archive@odin.ietf.org; Tue, 18 Mar 2003 21:54:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J2s6O10896; Tue, 18 Mar 2003 21:54:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J2pVO10789 for ; Tue, 18 Mar 2003 21:51:31 -0500 Received: from sunserver1.ietf56.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12592 for ; Tue, 18 Mar 2003 21:33:50 -0500 (EST) Received: from sunray129.wired.ietf56.ietf.org ([130.129.64.129] helo=BPenfield) by sunserver1.ietf56.ietf.org with smtp (Exim 4.12) id 18vTQw-00011z-00; Tue, 18 Mar 2003 21:36:02 -0500 Message-ID: <002d01c2edc0$46eb1370$81408182@BPenfield> From: "Bob Penfield" To: "Juergen Quittek" , "Martin Stiemerling" , References: <002701c2ed9e$7d7328f0$81408182@BPenfield> <44233634.1048037497@quittek.office> Subject: Re: [midcom] semantics does not allow agent to specify middlebox function Date: Tue, 18 Mar 2003 21:35:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 The twice-NAT in my scenario is actually twice-NAPT. It needs to reserve and ip-address/port pair on the inside and the outside. At one point (I think in Tom's early draft), the was a "CHOOSE" wildcard that could be specified as the internal or external address+port request parameter that would indicate to the middlebox that it needs to select/reserve a address-port. Alternatively a parameter indicated which ones (none, internal, external, or both) need to be selected be useful. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Juergen Quittek" To: "Bob Penfield" ; "Martin Stiemerling" ; Sent: Tuesday, March 18, 2003 7:31 PM Subject: Re: [midcom] semantics does not allow agent to specify middlebox function > Hi Bob, > > -- Bob Penfield wrote on 18 March 2003 17:34 -0500: > > > > > My point was that if the agent is talking to a middlebox that can do both > > NAPT and Twice-NAT, and the agent wants one or the other, it should be able > > to tell the middlebox which type it wants. > > The PRR request message contains a parameter (transport protocol) indicating > whether a NAT or NAPT service is requested by the agent. This is (hopefully > in a clear way) explained in the new section 2.3.5. > > So - at least for your example - the agent can chose between the NAPT and the > twice-NAT. > > I would not exclude the possibility that there are scenarios that are not > supported by our semantics, but so far, we did not find any. Further input > on this is very welcome. > > Cheers, > > Juergen > > > > The primary motivation for the original requirement was to be able to obtain > > a NAT binding and open the firewall pin-hole in a single transaction as > > opposed to two separate transaction and the semantics reflect that. > > > > I have always believed that this requirement meant that the agent could > > indicate which function or functions it wanted that the middlebox provided. > > > > For example, with a middlebox that provides traditional NAT functionality > > (i.e. NAPT on packets it sees rather than at the request of an agent) may > > have Twice-NAT capability and a VOIP midcom agent wants both an inside and > > an outside address when enabling an RTP flow. > > > > Why do we need to restrict the agent to one type of middlebox function? > > > > ----- Original Message ----- > > From: "Juergen Quittek" > > To: "Bob Penfield" ; "Martin Stiemerling" > > ; > > Sent: Tuesday, March 18, 2003 4:25 PM > > Subject: Re: [midcom] semantics does not allow agent to specify middlebox > > function > > > > > >> Hi Bob, > >> > >> Thanks a lot for reviewing the semantics! > >> > >> -- Bob Penfield wrote on 18 March 2003 14:16 -0500: > >> > >> > In section 2.3.6 the document states: > >> > > >> > When receiving the request, the middlebox determines how many > >> > address (and port) reservations are required based on its > >> > configuration. > >> > > >> > I believe that section 2.2.2 of RFC 3304 requires that the agent be able > > to > >> > indicate to the middlebox the desired function. > >> > > >> > The Midcom protocol must support the ability of an agent to install a > >> > ruleset that governs multiple types of middlebox actions (e.g. > >> > firewall and NAT). > >> > > >> > This states that a the protocol must support rules and actions for a > >> > variety of types of middleboxes. A Midcom agent ought to be able to > >> > have a single Midcom session with a middlebox and use the Midcom > >> > interface on the middlebox to interface with different middlebox > >> > functions on the same middlebox interface. > >> > > >> > This clearly states that the protocol must support a scenario where a > > given > >> > middlebox provides multiple functions and that the agent can specify > > which > >> > of those functions it wants for a given ruleset basis. > >> > >> That's an interesting comment that probably will end up in some > > clarifications > >> added to the semantics. > >> > >> We (at least intend to) realize section 2.2.2 of RFC 3304 by having just > > an > >> "enable" policy action telling the middlebox: Whatever you need to do for > > realizing > >> this, please do so. This includes all required pinhole creations and > > binding > >> establishments, inependent of the type of middlebox. In general, the agent > > should > >> be able to communicate with the middlebox without considering what kind of > > box > >> it is talking to. > >> > >> The phrase you cited > >> > >> > In section 2.3.6 the document states: > >> > > >> > When receiving the request, the middlebox determines how many > >> > address (and port) reservations are required based on its > >> > configuration. > >> > >> is probably misleading as it is written now. It just replects that > >> - a firewall does not need to perform any reservation > >> - a traditonal NAT only needs to perform reservations on the external > >> side > >> - a twice-NAT needs to perform reservations on the external side as > >> well as on the internal side. > >> > >> The middlebox then returns the reservations made. > >> > >> I think that this completely meets the the requirement stated in > >> section 2.2.2 of RFC 3304. > >> > >> Cheers, > >> > >> Juergen > >> > >> > cheers, > >> > (-:bob > >> > > >> > Robert F. Penfield > >> > Chief Software Architect > >> > Acme Packet, Inc. > >> > 130 New Boston Street > >> > Woburn, MA 01801 > >> > bpenfield@acmepacket.com > >> > > >> > ----- Original Message ----- > >> > From: "Martin Stiemerling" > >> > To: > >> > Sent: Monday, March 17, 2003 12:52 PM > >> > Subject: [midcom] Changes in the semantics I-D > >> > > >> > > >> >> Hi, > >> >> > >> >> as posted earlier on this list a new version of the MIDCOM semantics > > I-D > >> >> is available. The major changes in this version are: > >> >> > >> >> - Complete reworked group behaviour: > >> >> As agreed the groups are not created explicitly by the Group > >> >> Establishment (GE) transaction anymore, but they are created implicit > >> >> through a PER or PRR transactions type. A group is deleted after the > >> >> last policy rule of this pariticular group has been deleted. There is > > no > >> >> lifetime of a group anymore. The lifetime a group is equal to the > >> >> maximum of all policy rule lifetimes. So the GE transaction is dropped, > >> >> as well as the AGD notification. > >> >> > >> >> - reworked the draft regarding wildcarding, address and transport > >> >> address in order to provide a more clear view on this topic > >> >> > >> >> - adapted the examples to latest changes > >> >> > >> >> 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 > >> >> > >> > > >> > _______________________________________________ > >> > 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 mailnull@www1.ietf.org Tue Mar 18 22:01:16 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 WAA13268 for ; Tue, 18 Mar 2003 22:01:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J3IQl12843 for midcom-archive@odin.ietf.org; Tue, 18 Mar 2003 22:18:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J3I6O12826; Tue, 18 Mar 2003 22:18:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J3F4O12732 for ; Tue, 18 Mar 2003 22:15:04 -0500 Received: from sunserver1.ietf56.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13160 for ; Tue, 18 Mar 2003 21:57:23 -0500 (EST) Received: from sunray129.wired.ietf56.ietf.org ([130.129.64.129] helo=BPenfield) by sunserver1.ietf56.ietf.org with smtp (Exim 4.12) id 18vTnj-00013c-00 for midcom@ietf.org; Tue, 18 Mar 2003 21:59:35 -0500 Message-ID: <003601c2edc3$9115dd10$81408182@BPenfield> From: "Bob Penfield" To: "midcom" Date: Tue, 18 Mar 2003 21:59:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [midcom] need for PRR and PER 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 I want to clarify what I was saying at the meeting. Since RTP does not have to be symmetric, you need two policy rules. One for the inbound RTP, and one for the outbound RTP. Consider a SIP call from A to B. +------------[agent]-------------+ | | | [A]=========I[middlebox]E========[B] ------ is SIP ====== is RTP When the SIP INVITE traverses the agent, it has enough information to enable the inbound flow (using a wildcard for the external source address+port B). However, it does not have enough information to enable a policy rule for the outbound flow. When the response traverses the agent, the outbound flow can be enabled. The problem is that if by the time the response comes back, the middlebox might not have enough resources (whatever they may be) to enable the outbound flow, the call fails. If the outbound policy rule could be created (without being enabled), then this sort of failure can be avoided. With the existing semantics, a PRR would be used to reserve the outbound flow and select the external address+port (E). A PER would then be used to enable the inbound flow using (E) from the PRR response as the inbound destination address+port (the external address+port). When the response came back, a PER would be used to enabled the previously reserved rule for the outbound flow. It would be nice if both transactions could be completed in one request/response, but that's a different problem. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Mar 20 19:53:58 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 TAA16149 for ; Thu, 20 Mar 2003 19:53:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2L1C4w14060 for midcom-archive@odin.ietf.org; Thu, 20 Mar 2003 20:12:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L1BSO14040; Thu, 20 Mar 2003 20:11:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L18MO13920 for ; Thu, 20 Mar 2003 20:08:22 -0500 Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16072; Thu, 20 Mar 2003 19:49:43 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h2L0q0Z20787; Thu, 20 Mar 2003 16:52:00 -0800 (PST) Message-Id: <200303210052.h2L0q0Z20787@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, midcom@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 20 Mar 2003 16:51:59 -0800 Subject: [midcom] RFC 3489 on STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) 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 Request for Comments is now available in online RFC libraries. RFC 3489 Title: STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) Author(s): J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy Status: Standards Track Date: March 2003 Mailbox: jdrosen@dynamicsoft.com, jweinberger@dynamicsoft.com, huitema@microsoft.com, rohan@cisco.com Pages: 47 Characters: 117562 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-midcom-stun-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3489.txt Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol (IP) addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. This document is a product of the Middlebox Communication Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030320164901.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3489 --OtherAccess Content-Type: Message/External-body; name="rfc3489.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030320164901.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Mar 21 08:51:22 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 IAA13393 for ; Fri, 21 Mar 2003 08:51:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LE9j807410 for midcom-archive@odin.ietf.org; Fri, 21 Mar 2003 09:09:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LE9LO07399; Fri, 21 Mar 2003 09:09:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LE6bO06585 for ; Fri, 21 Mar 2003 09:06:37 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13371 for ; Fri, 21 Mar 2003 08:47:43 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.8/8.12.8) with ESMTP id h2LDn9Cx048892; Fri, 21 Mar 2003 14:49:12 +0100 (CET) Received: from ccrle.nec.de (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 05C497655B; Fri, 21 Mar 2003 14:49:05 +0100 (CET) Message-ID: <3E7B181B.8070800@ccrle.nec.de> Date: Fri, 21 Mar 2003 14:48:11 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: asimu@cisco.com Cc: "'Bob Penfield'" , midcom@ietf.org Subject: Re: [midcom] semantics does not allow agent to specify middleboxfunction References: <005401c2edad$f88bc5b0$264947ab@amer.cisco.com> Content-Type: multipart/alternative; boundary="------------090602040008040302050804" 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: , --------------090602040008040302050804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ok, I see. Thanks Martin Adina Simu (asimu) wrote: >There are middleboxes which can do both -- based on criteria like one of >the addresses, both addresses, direction of traffic, etc. one or both >types of translations are used. > >-Adina > > > >>-----Original Message----- >>From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On >>Behalf Of Martin Stiemerling >>Sent: Tuesday, March 18, 2003 2:52 PM >>To: Bob Penfield >>Cc: midcom@ietf.org >>Subject: Re: [midcom] semantics does not allow agent to >>specify middleboxfunction >> >> >>A basic question of understanding (inline): >> >>Bob Penfield wrote: >> >> >>>If the middlebox is capable of both NAPT and Twice-NAT, how >>> >>> >>does the >> >> >>>middlebox know which one the agent wants? >>> >>> >>Are there middleboxes out there in operation that can do >>either NAPT or >>twice-NAT and switch instantly? >>With NAPT you mean Network Address and Port Translation, right? >> >>Martin >> >> >> >>> >>> >>>>> This states that a the protocol must support rules and >>>>> >>>>> >>actions for >> >> >>>>>a >>>>> >>>>> >>_______________________________________________ >>midcom mailing list >>midcom@ietf.org >>https://www1.ietf.org/mailman/listinfo/midcom >> >> >> > > > --------------090602040008040302050804 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Ok, I see.

Thanks
Martin


Adina Simu (asimu) wrote:
There are middleboxes which can do both -- based on criteria like one of
the addresses, both addresses, direction of traffic, etc. one or both
types of translations are used.

-Adina

  
-----Original Message-----
From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On 
Behalf Of Martin Stiemerling
Sent: Tuesday, March 18, 2003 2:52 PM
To: Bob Penfield
Cc: midcom@ietf.org
Subject: Re: [midcom] semantics does not allow agent to 
specify middleboxfunction


A basic question of understanding (inline):

Bob Penfield wrote:
    
If the middlebox is capable of both NAPT and Twice-NAT, how 
      
does the 
    
middlebox know which one the agent wants?
      
Are there middleboxes out there in operation that can do 
either NAPT or 
twice-NAT and switch instantly?
With NAPT you mean Network Address and Port Translation, right?

Martin

    
      
  This states that a the protocol must support rules and 
          
actions for 
    
a
          
_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom

--------------090602040008040302050804-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Mar 21 08:55:01 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 IAA13480 for ; Fri, 21 Mar 2003 08:55:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LEDOL07594 for midcom-archive@odin.ietf.org; Fri, 21 Mar 2003 09:13:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LED3O07576; Fri, 21 Mar 2003 09:13:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LE7iO07372 for ; Fri, 21 Mar 2003 09:07:44 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13385 for ; Fri, 21 Mar 2003 08:48:50 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.8/8.12.8) with ESMTP id h2LDp6Cx049123; Fri, 21 Mar 2003 14:51:06 +0100 (CET) Received: from ccrle.nec.de (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id CB9738DA80; Fri, 21 Mar 2003 14:51:02 +0100 (CET) Message-ID: <3E7B188C.5080808@ccrle.nec.de> Date: Fri, 21 Mar 2003 14:50:04 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Penfield Cc: midcom@ietf.org Subject: Re: [midcom] semantics does not allow agent to specify middlebox function References: <3E760B73.5060508@ccrle.nec.de> <002b01c2ed82$e18e5c90$81408182@BPenfield> <3E778FE6.5050606@ccrle.nec.de> <003301c2ed9e$c9bbf7f0$81408182@BPenfield> <3E77A306.5020108@ccrle.nec.de> <001d01c2edbf$18e284f0$81408182@BPenfield> Content-Type: multipart/alternative; boundary="------------040603050205000804080508" 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: , --------------040603050205000804080508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > >>Are there middleboxes out there in operation that can do either NAPT or >>twice-NAT and switch instantly? >>With NAPT you mean Network Address and Port Translation, right? >> >>Martin >> >> >> > >I know of at least one box that is capable of NAPT and Twice-NAT (actually >twice-NAPT) on a rule-by-rule basis. > Ok, thanks, we will consider this, as Juergen told before, in the next version of the semantics. Thanks for the hint Martin --------------040603050205000804080508 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Are there middleboxes out there in operation that can do either NAPT or
twice-NAT and switch instantly?
With NAPT you mean Network Address and Port Translation, right?

Martin

    

I know of at least one box that is capable of NAPT and Twice-NAT (actually
twice-NAPT) on a rule-by-rule basis.
Ok, thanks, we will consider this, as Juergen told before, in the next version of the semantics.

Thanks for the hint
Martin
--------------040603050205000804080508-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Mar 21 16:13:34 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 QAA27777 for ; Fri, 21 Mar 2003 16:13:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LLW4O07110 for midcom-archive@odin.ietf.org; Fri, 21 Mar 2003 16:32:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LLVGO07061; Fri, 21 Mar 2003 16:31:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LLSBO06922 for ; Fri, 21 Mar 2003 16:28:11 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27663 for ; Fri, 21 Mar 2003 16:09:09 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2LLBUBd002985 for ; Fri, 21 Mar 2003 16:11:30 -0500 (EST) Message-ID: <3E7B7FFD.4070204@dynamicsoft.com> Date: Fri, 21 Mar 2003 16:11:25 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: midcom@ietf.org Subject: Re: [midcom] RFC 3489 on STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) References: <200303210052.h2L0q0Z20787@gamma.isi.edu> 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 As you can see, STUN is now available as RFC 3489. There were a few changes during authors 48. The vast majority were clarifications. A few were bug fixes. THe most significant, which we discussed on the list, was the change back to 0x01 for the IPv4 address family: Section 11.2.1, text after the figure: OLD: The port is a network byte ordered representation of the mapped port. The address family is always 0x02, corresponding to IPv4. NEW: The port is a network byte ordered representation of the mapped port. The address family is always 0x01, corresponding to IPv4. ^^^^ Here are the rest of the bug fixes that we sent: Section 7, sixth paragraph: OLD: The seventh attribute, PASSWORD, is only found in Binding Response messages. NEW: The seventh attribute, PASSWORD, is only found in Shared Secret ^^^^^^^^^^^^^ Response messages. Section 7, sixth paragraph: OLD: The ninth attribute is the ERROR-CODE attribute. This is present in the Binding Error Response. NEW: The ninth attribute is the ERROR-CODE attribute. This is present in the Binding Error Response and Shared Secret Error Response. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Section 9.1 paragraph 3: OLD: For STUN requests, failure occurs if there is a transport failure of some sort (generally, due to fatal ICMP errors in UDP or connection failures in TCP). Failure also occurs if the the request does not solicit a response after 30 seconds. If a failure occurs, the client SHOULD create a new request, which is identical to the previous, but has a different transaction ID. That request is sent to the next element in the list as specified by RFC 2782. NEW (replace with): For STUN requests, failure occurs if there is a transport failure of some sort (generally, due to fatal ICMP errors in UDP or connection failures in TCP). Failure also occurs if the transaction fails due to timeout. This occurs 9.5 seconds after the first request is sent, for both Shared Secret Requests and Binding Requests. See Section 9.3 for details on transaction timeouts for Binding Requests. If a failure occurs, the client SHOULD create a new request, which is identical to the previous, but has a different transaction ID and MESSAGE INTEGRITY attribute (the HMAC will change because the transaction ID has changed). That request is sent to the next element in the list as specified by RFC 2782. Section 9.2, paragpraph 4: OLD: Interpretation of those response codes is identical to the processing of Section 9.4 for the Shared Secret Error Response. NEW: Interpretation of those response codes is identical to the processing of Section 9.4 for the Binding Error Response. ^^^^^^^ Section 9.3, last paragraph: OLD: Retransmissions continue with intervals of 1.6s until a response is received, or a total of 9 requests have been sent, at which time the client SHOULD give up. NEW (replace with): Retransmissions continue with intervals of 1.6s until a response is received, or a total of 9 requests have been sent. If no response is received by 1.6 seconds after the last request has been sent, the client SHOULD consider the transaction to have failed. In other words, requests would be sent at times 0ms, 100ms, 300ms, 700ms, 1500ms, 3100ms, 4700ms, 6300ms, and 7900ms. At 9500ms, the client considers the transaction to have failed if no response has been received. Section 11.2.8: OLD: The text used as input to HMAC is the STUN message, including the header, up to and including the attribute preceding the MESSAGE- INTEGRITY attribute. NEW: The text used as input to HMAC is the STUN message, including the header, up to and including the attribute preceding the MESSAGE- INTEGRITY attribute. That text is then padded with zeroes so as to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ be a multiple of 64 bytes. ^^^^^^^^^^^^^^^^^^^^^^^^^^ Section 11.2.9 first paragraph: OLD: The ERROR-CODE attribute is present in the Binding Error Response and Shared Secret Error Response. It is a numeric value in the range of 100 to 699 plus a textual reason phrase, and is consistent in its NEW: The ERROR-CODE attribute is present in the Binding Error Response and Shared Secret Error Response. It is a numeric value in the range of 100 to 699 plus a textual reason phrase encoded in UTF-8, and is ^^^^^^^^^^^^^^^^ consistent in its Thanks, Jonathan R. rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 3489 > > Title: STUN - Simple Traversal of User Datagram Protocol > (UDP) Through Network Address Translators (NATs) > Author(s): J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy > Status: Standards Track > Date: March 2003 > Mailbox: jdrosen@dynamicsoft.com, > jweinberger@dynamicsoft.com, > huitema@microsoft.com, rohan@cisco.com > Pages: 47 > Characters: 117562 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-midcom-stun-05.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3489.txt > > > Simple Traversal of User Datagram Protocol (UDP) Through Network > Address Translators (NATs) (STUN) is a lightweight protocol that > allows applications to discover the presence and types of NATs and > firewalls between them and the public Internet. It also provides the > ability for applications to determine the public Internet Protocol > (IP) addresses allocated to them by the NAT. STUN works with many > existing NATs, and does not require any special behavior from them. > As a result, it allows a wide variety of applications to work through > existing NAT infrastructure. > > This document is a product of the Middlebox Communication Working > Group of the IETF. > > This is now a Proposed Standard Protocol. > > This document specifies an Internet standards track protocol for > the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the > "Internet Official Protocol Standards" (STD 1) for the > standardization state and status of this protocol. Distribution > of this memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution.echo > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Mar 24 17:56:48 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 RAA07140 for ; Mon, 24 Mar 2003 17:56:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ONGnu09074 for midcom-archive@odin.ietf.org; Mon, 24 Mar 2003 18:16:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONGCO09060; Mon, 24 Mar 2003 18:16:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ON5vO07737 for ; Mon, 24 Mar 2003 18:05:57 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06658 for ; Mon, 24 Mar 2003 17:45:24 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2OMlh4c013912 for ; Mon, 24 Mar 2003 14:47:43 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AFB22687; Mon, 24 Mar 2003 14:47:42 -0800 (PST) Message-Id: <200303242247.AFB22687@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Mon, 24 Mar 2003 17:47:42 -0500 Subject: [midcom] On SNMPv3, clarification, invitation for discussion 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: , At the midcom meeting last week David Harrington raised the issue of a recent policy change in the OPS area, which is that because the use of SNMP for configuration hasn't accelerated as expected, the OPS area seems to be moving towards XML for configuration (no protocol specified). There's a new policy that writable MIBs are no longer required. This raised the question of whether or not we want to continue with SNMPv3 as the midcom protocol, and we had a lengthy discussion about what the actual issues are. One thing to consider is that the environment in which we expect midcom to be deployed is substantially different from the environment in which people might be using SNMP for static device configuration. After the meeting I spent some time talking with Mary and David, and they seem willing to continue the work (although they'd appreciate more feedback from the working group). The first draft of their work should be out very soon and we expect that it won't take more than a few months to wrap it up and deliver it to the IESG. While the future may indeed turn out to be XMLCONF, 1) that working group isn't even chartered yet, and 2) the group that's developing it is using the same data model as SMIng, and there are compilers that take a MIB and turn it into an XML document. That is to say, MIB work now will be reusable with XMLCONF later. I attended the OPS area meeting where this information was confirmed. It's not that SNMP is being deprecated or even that the use of SNMP for configuration is being deprecated. It's that writable MIBs are no longer mandatory. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Mar 24 18:58:53 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 SAA10241 for ; Mon, 24 Mar 2003 18:58:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P0IuA13099 for midcom-archive@odin.ietf.org; Mon, 24 Mar 2003 19:18:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0ILO13065; Mon, 24 Mar 2003 19:18:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0FFO12981 for ; Mon, 24 Mar 2003 19:15:15 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10129 for ; Mon, 24 Mar 2003 18:54:41 -0500 (EST) Received: from cisco.com (sjc-vpn2-127.cisco.com [10.21.112.127]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA02976; Mon, 24 Mar 2003 15:57:01 -0800 (PST) Message-ID: <3E7F9B4B.1020303@cisco.com> Date: Mon, 24 Mar 2003 15:56:59 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Melinda Shore CC: midcom@ietf.org Subject: Re: [midcom] On SNMPv3, clarification, invitation for discussion References: <200303242247.AFB22687@mira-sjc5-c.cisco.com> In-Reply-To: <200303242247.AFB22687@mira-sjc5-c.cisco.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 Melinda, Two more additions to your valid comments. XMLCONF has an intended audience: configuration and retrieval of static information within devices. This may be slightly imprecise, but let me tell you what we *don't* think XMLCONF is good for: exchange of protocol state information. We wouldn't want to replace BGP with XMLCONF, for example. I believe midcom comes a lot closer to a state exchange protocol, such as BGP, then it does to the screen scraping that we are attempting to address with NET-CONF. Certainly this holds true for STUN, and that's a good hint, IMHO. ALSO. To repeat what Bert, Andy, and others have said, while the requirement has been relaxed, there is nothing stopping anyone from writing a MIB or specification with writable objects. You simply aren't REQUIRED to do so. If this group believes that SNMP with writable objects is the right way to go, I say go for it. Eliot _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Mar 25 15:32:21 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 PAA01949 for ; Tue, 25 Mar 2003 15:32:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PKqmd13034 for midcom-archive@odin.ietf.org; Tue, 25 Mar 2003 15:52:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKqHO12995; Tue, 25 Mar 2003 15:52:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKnAO12782 for ; Tue, 25 Mar 2003 15:49:10 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01591 for ; Tue, 25 Mar 2003 15:28:12 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2PKUNI12707; Tue, 25 Mar 2003 15:30:23 -0500 (EST) 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 GDFCRTLZ; Tue, 25 Mar 2003 15:30:23 -0500 Received: from nortelnetworks.com (acart1cb.ca.nortel.com [47.129.129.54]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G7ZYWJJT; Tue, 25 Mar 2003 15:30:24 -0500 Message-ID: <3E80BC5B.20706@nortelnetworks.com> Date: Tue, 25 Mar 2003 15:30:19 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Melinda Shore , midcom@ietf.org Subject: Re: [midcom] On SNMPv3, clarification, invitation for discussion References: <200303242247.AFB22687@mira-sjc5-c.cisco.com> In-Reply-To: <200303242247.AFB22687@mira-sjc5-c.cisco.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 The real issue is deployability of a MIDCOM protocol. We heard that the operators we are targetting for MIDCOM are not enabling SNMP SET operations. Jonathan was saying this was on grounds of cost. Other interpretations are certainly possible. The point is that operators will enable a MIDCOM protocol only if they are convinced that they have adequate control over its operation, whether it be SNMPv3 or SIMCO. We need to hear from operators on what would convince them that the risks are acceptable, and that may well call for an extended risk analysis on our part. In the meantime, I think the additional configuration constraints Juergen and Martin proposed in their semantics document open issues list are a move in the right direction. Quoting from Melinda's E-mail: "Semantics Document" sent to the list on 2003-03-10: - Shall the agent be able to specify parameters for protection against denial of service attacks? Examples are - maximum total number of TCP connection setups allowed - maximum number of TCP connection setups per minute - maximum number of UDP packets per minute - maximum bit rate - ... I think we should be thinking along these lines. Melinda Shore wrote: > At the midcom meeting last week David Harrington raised the > issue of a recent policy change in the OPS area, which is > that because the use of SNMP for configuration hasn't > accelerated as expected, the OPS area seems to be moving > towards XML for configuration (no protocol specified). > There's a new policy that writable MIBs are no longer > required. > > This raised the question of whether or not we want to continue > with SNMPv3 as the midcom protocol, and we had a lengthy > discussion about what the actual issues are. One thing to > consider is that the environment in which we expect midcom > to be deployed is substantially different from the > environment in which people might be using SNMP for static > device configuration. > > After the meeting I spent some time talking with Mary and > David, and they seem willing to continue the work (although > they'd appreciate more feedback from the working group). > The first draft of their work should be out very soon and we > expect that it won't take more than a few months to wrap it > up and deliver it to the IESG. While the future may indeed > turn out to be XMLCONF, 1) that working group isn't even > chartered yet, and 2) the group that's developing it is > using the same data model as SMIng, and there are compilers > that take a MIB and turn it into an XML document. That is > to say, MIB work now will be reusable with XMLCONF later. > > I attended the OPS area meeting where this information was > confirmed. It's not that SNMP is being deprecated or even > that the use of SNMP for configuration is being deprecated. > It's that writable MIBs are no longer mandatory. > > 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 mailnull@www1.ietf.org Tue Mar 25 15:46:07 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 PAA02678 for ; Tue, 25 Mar 2003 15:46:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PL6YT14096 for midcom-archive@odin.ietf.org; Tue, 25 Mar 2003 16:06:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PL67O14064; Tue, 25 Mar 2003 16:06:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PL3IO13907 for ; Tue, 25 Mar 2003 16:03:18 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02542 for ; Tue, 25 Mar 2003 15:42:20 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2PKic4c026588; Tue, 25 Mar 2003 12:44:39 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AFD15115; Tue, 25 Mar 2003 12:44:37 -0800 (PST) Message-Id: <200303252044.AFD15115@mira-sjc5-c.cisco.com> To: Tom Taylor cc: midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] On SNMPv3, clarification, invitation for discussion In-Reply-To: Message from taylor@nortelnetworks.com of "Tue, 25 Mar 2003 15:30:19 EST." <3E80BC5B.20706@nortelnetworks.com> Date: Tue, 25 Mar 2003 15:44:37 -0500 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: , > The real issue is deployability of a MIDCOM protocol. We > heard that the operators we are targetting for MIDCOM are > not enabling SNMP SET operations. To be clear, what we heard is that the operators who were in the room at the time that a show of hands was requested are not enabling SNMP SET operations. This doesn't include enterprises and it's a highly biased sample. It also doesn't address the question of whether or not they'd enable them in order to support new applications. However, I do agree that we need to close the questions Martin has raised, and we'll try to do that over the next several weeks in preparation for a final draft to put into WG last call. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Mar 25 18:19:22 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 SAA10643 for ; Tue, 25 Mar 2003 18:19:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PNdrp27557 for midcom-archive@odin.ietf.org; Tue, 25 Mar 2003 18:39:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PNdLO27538; Tue, 25 Mar 2003 18:39:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PNZdO26621 for ; Tue, 25 Mar 2003 18:35:39 -0500 Received: from localhost.localdomain (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10354 for ; Tue, 25 Mar 2003 18:14:36 -0500 (EST) Received: (from hardaker@localhost) by localhost.localdomain (8.11.6/8.11.6) id h2PNGlT22008; Tue, 25 Mar 2003 15:16:47 -0800 To: "Harrington, David" Cc: "Midcom (E-mail)" Subject: Re: [midcom] firewall mib/ipsec policy config mib From: Wes Hardaker X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: Network Associates Laboratories Date: Tue, 25 Mar 2003 15:16:47 -0800 In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA489443@NHROCMBX1.ets.enterasys.com> ("Harrington, David"'s message of "Mon, 10 Mar 2003 19:11:44 -0500") Message-ID: User-Agent: Gnus/5.090015 (Oort Gnus v0.15) XEmacs/21.5 (brussels sprouts, i686-pc-linux) References: <6D745637A7E0F94DA070743C55CDA9BA489443@NHROCMBX1.ets.enterasys.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: , >>>>> On Mon, 10 Mar 2003 19:11:44 -0500, "Harrington, David" said: David> The IPSec Policy Configuration MIB (and related non-mib David> documents) are likely to advance to Proposed Standard status David> soon. Some of this mib's objects may apply to firewall and ACL David> configuration. David> It would be good if the WG could review the mib design and David> comment about its applicability in the MIDCOM environment. Note David> that an implementation has already been done to work with David> NET-SNMP. Specifically, it's based on Net-SNMP and linux (though the management interface should run on most platforms) and is available as a separate project from Net-SNMP at http://net-policy.sourceforge.net/ . -- Wes Hardaker Network Associates Laboratories _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Mar 25 18:43:41 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 SAA11412 for ; Tue, 25 Mar 2003 18:43:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q04CY28568 for midcom-archive@odin.ietf.org; Tue, 25 Mar 2003 19:04:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q03jO28531; Tue, 25 Mar 2003 19:03:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PNtJO28172 for ; Tue, 25 Mar 2003 18:55:19 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11103 for ; Tue, 25 Mar 2003 18:34:17 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2PNaa4c002773 for ; Tue, 25 Mar 2003 15:36:37 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AFD42405; Tue, 25 Mar 2003 15:36:33 -0800 (PST) Message-Id: <200303252336.AFD42405@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Tue, 25 Mar 2003 18:36:32 -0500 Subject: [midcom] Wildcarding/reservations 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: , These two issues have become intermingled in our discussions of the semantics document, and so they may require discussion together, at least at first. There are two questions that need to be resolved for the semantics document (and, indeed, for the protocol): 1) should the midcom protocol support wildcards?, and 2) should the process of installing a rule be broken into two steps, a reservation request and and a request to enable a reservation? Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Mar 25 19:38:22 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 TAA12972 for ; Tue, 25 Mar 2003 19:38:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q0ws500309 for midcom-archive@odin.ietf.org; Tue, 25 Mar 2003 19:58:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q0wHO32747; Tue, 25 Mar 2003 19:58:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q0tDO32643 for ; Tue, 25 Mar 2003 19:55:13 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12900 for ; Tue, 25 Mar 2003 19:34:09 -0500 (EST) Received: by fox.iptel.org (Postfix, from userid 534) id 305C0211; Wed, 26 Mar 2003 01:36:24 +0100 (CET) Received: from jku07.fokus.fraunhofer.de (dhcp186.fokus.fraunhofer.de [195.37.78.186]) by fox.iptel.org (Postfix) with ESMTP id 7F171208; Wed, 26 Mar 2003 01:36:23 +0100 (CET) Message-Id: <5.2.0.9.0.20030326013116.03af3e30@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 26 Mar 2003 01:35:46 +0100 To: Melinda Shore , midcom@ietf.org From: Jiri Kuthan Subject: Re: [midcom] Wildcarding/reservations In-Reply-To: <200303252336.AFD42405@mira-sjc5-c.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-13.5 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO autolearn=ham version=2.51 X-Spam-Checker-Version: SpamAssassin 2.51 (1.174.2.5-2003-03-20-exp) 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: , At 12:36 AM 3/26/2003, Melinda Shore wrote: >1) should the midcom protocol support wildcards?, and There are applications which need that. >2) should the process of installing a rule be broken into > two steps, a reservation request and and a request to > enable a reservation? I'm not sure if there is a benefit in doing so. I guess it makes sense if - the application is of request-response style - with request tied to a midcom reservation and response tied to a midcom commit - and some additional security value one can infer from the response -Jiri _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Mar 26 14:01:33 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 OAA07522 for ; Wed, 26 Mar 2003 14:01:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QJMSU23918 for midcom-archive@odin.ietf.org; Wed, 26 Mar 2003 14:22:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJLMO23802; Wed, 26 Mar 2003 14:21:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJGIO23576 for ; Wed, 26 Mar 2003 14:16:18 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07267 for ; Wed, 26 Mar 2003 13:54:51 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.8/8.12.8) with ESMTP id h2QIuoCx074198; Wed, 26 Mar 2003 19:56:50 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id BD4A8963C9; Wed, 26 Mar 2003 19:55:55 +0100 (CET) Date: Wed, 26 Mar 2003 19:57:31 +0100 From: Juergen Quittek To: Melinda Shore , midcom@ietf.org Subject: Re: [midcom] Wildcarding/reservations Message-ID: <9179028.1048708650@[10.1.1.26]> In-Reply-To: <200303252336.AFD42405@mira-sjc5-c.cisco.com> References: <200303252336.AFD42405@mira-sjc5-c.cisco.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit 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 -- Melinda Shore wrote on 25 March 2003 18:36 -0500: > > These two issues have become intermingled in our discussions > of the semantics document, and so they may require > discussion together, at least at first. > > There are two questions that need to be resolved for the > semantics document (and, indeed, for the protocol): > > 1) should the midcom protocol support wildcards?, and I think in the end of the session there was an agreement that wildcarding is needed. > 2) should the process of installing a rule be broken into > two steps, a reservation request and and a request to > enable a reservation? I think it is needed for firewalls that implement highly protective security policies. For less protective policies it is not required. Juergen > Thanks, > > 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 mailnull@www1.ietf.org Wed Mar 26 17:35:46 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 RAA18711 for ; Wed, 26 Mar 2003 17:35:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QMujm10441 for midcom-archive@odin.ietf.org; Wed, 26 Mar 2003 17:56:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QMuFO10425; Wed, 26 Mar 2003 17:56:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QMqvO10314 for ; Wed, 26 Mar 2003 17:52:57 -0500 Received: from NREXCH.netrake.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18609 for ; Wed, 26 Mar 2003 17:31:27 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] Wildcarding/reservations Date: Wed, 26 Mar 2003 16:34:37 -0600 Message-ID: <7E06D3212981524CA10D2A114937C414B20BF1@nrexch.netrake.net> Thread-Topic: [midcom] Wildcarding/reservations Thread-Index: AcLzKVGP/EwcYyZ7R/GeUG9sTXZJPQAvN5WQ From: "Jasson Casey" To: "Melinda Shore" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2QMqvO10315 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: 8bit 1. This is necessary. As I've mentioned before a typical signaling sequence only represents the destination ip/port for media streams. It can be very dangerous to assume asymmetric relationships between SDP in the INVITE/200. There are implementations that wildcarding is not necessary; however, there are also implementations where only port wildcarding would be necessary, and then applications where both port and ip wildcarding becomes necessary. I have noticed the need for port wildcarding with certain gateways, I have noticed the need for ip wildcarding with certain multi-interface gateways, and also in enhanced environments (announcement server sends a RTP flow that says, "you have 30 seconds left,"). 2. I believe this is necessary. A MA/MB combination only has one opportunity to fail a call; on the initial outgoing request. If for whatever reason a failure scenario should occur during the successful final response (2XX) the MB/MA combination cannot do much to rectify the situation; except try to tear down the existing dialog(s). Reservation sounds like a good idea; however, it is really only a prediction (in this particular use case) of what will be necessary on the media descriptors in the final response. This could lead into tying these requirements together: MA ---> MB request(src_ip=*,src_p=*,dst_ip=*,dst_p=*), where the response states the status of the request (success/failure), and the MB_src_ip/p for particular media flow. Then the dst_x parameters would be modified with explicit addresses once they are learned. The exact purpose of this would be to prevent against MB exhaustion of pinhole resources. Again this is just a thought with a particular scenario, I'm su! re there are other, better reasons. Jasson Casey jasson@netrake.com -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Tuesday, March 25, 2003 5:37 PM To: midcom@ietf.org Subject: [midcom] Wildcarding/reservations These two issues have become intermingled in our discussions of the semantics document, and so they may require discussion together, at least at first. There are two questions that need to be resolved for the semantics document (and, indeed, for the protocol): 1) should the midcom protocol support wildcards?, and 2) should the process of installing a rule be broken into two steps, a reservation request and and a request to enable a reservation? Thanks, 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 mailnull@www1.ietf.org Wed Mar 26 22:27:25 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 WAA00652 for ; Wed, 26 Mar 2003 22:27:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R3mTb30827 for midcom-archive@odin.ietf.org; Wed, 26 Mar 2003 22:48:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R3ldO30742; Wed, 26 Mar 2003 22:47:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R3iKO30628 for ; Wed, 26 Mar 2003 22:44:20 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00519 for ; Wed, 26 Mar 2003 22:22:45 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2R3P3Q04599 for ; Wed, 26 Mar 2003 22:25:04 -0500 (EST) 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 GDF48PB3; Wed, 26 Mar 2003 22:25:03 -0500 Received: from nortelnetworks.com (acart1cb.ca.nortel.com [47.129.129.54]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G7ZYWJ5P; Wed, 26 Mar 2003 22:25:04 -0500 Message-ID: <3E826F0C.3030109@nortelnetworks.com> Date: Wed, 26 Mar 2003 22:25:00 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Comments On The Semantics Draft 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 may look odd for me as co-author to be commenting on this draft, but Martin and Juergen didn't have time to wave the latest version past me before submitting it. I've submitted a bunch of purely editorial markup directly to them. Section 2.1.2 Atomicity: ------------------------- The last sentence of the first paragraph reads: "However, asynchronous notification transactions may interrupt and terminate processing of a request at any time." This is not quite accurate -- it seems to imply that the middlebox receives asynchronous notification transactions rather than generating them. I suggest the following instead: "However, events other than the receipt of requests may interrupt processing of a request, influence the outcome of that request, and cause the middlebox to generate an asynchronous notification before responding to the request." It is clear from text in 2.2.3 that some requests are never answered (e.g. those queued for processing when a session is terminated). I suppose it is unnecessary to go into the detail of whether a request on which processing has begun may not terminate in a response. Section 2.2.1 Session Establishment ----------------------------------- If the agent needs to know the middlebox's functions, they are probably best expressed as a set drawn from {firewall, NAT, PT}. Per Bob Cunningham's point, we probably also have to indicate twice-NAT capability. Section 2.2.4 Session Termination By Interruption Of Connection --------------------------------------------------------------- I don't think MIDCOM should be tied to transport at the level of semantics: this is a protocol issue. I think this section should be deleted. Section 2.3.5 Address Parameter Constraints -------------------------------------------- We have now determined that the third paragraph of this section, stating: "The specified IP address cannot be wildcarded.", should be changed. Further down, this section assigns a meaning to port value zero. Since this is a description of semantics rather than an actual protocol, an abstract value such as 'ANY' should be used. The same paragraph ends: "Depending on the value of the transport protocol parameter, this parameter may truly refer to ports, or may refer to an equivalent concept." This is inconsistent with the preceding paragraph, where it is stated that port is irrelevant for the transport protocol value ANY. I would suggest keeping this latter statement, as the path of least resistance. We can always provide details for particular protocols later. Section 2.3.6 Policy Reserve Rule (PRR) --------------------------------------- Specific address values are given to represent unassigned addresses. For a semantic description, an abstract value such as 'UNASSIGNED' should be used. Section 2.3.7 Policy Enable Rule (PER) -------------------------------------- I note that the group number is assigned independently of the group number of any predecessor reserve rule, rather than being inherited from the reserve rule. Does this make sense to people? Section 2.3.9 Policy Rule Status (PRS) -------------------------------------- There should be text added for the direction reply parameter, indicating that it appears only for enable rules. Section 2.3.11 Policy Rule State Machine ---------------------------------------- Given the separation of the reserve rule from its successor enable rule in the preceding text, we actually need to portray two different state machines, possibly interlinked. Alternatively, since the diagram actually shows the states of a PRID rather than a rule, the "may" stated for reuse of PRID in going from reserve to enable rule could be made a MUST. Then only one state machine would be required. Section 2.4.2 Group Lifetime Change (GLC) ----------------------------------------- We might want to add text noting that setting a group lifetime to zero will cause the middlebox to send Asynchronous Policy Rule Deletion (ARD) notifications for all of the rules concerned, to all agents allowed access to those rules. This is obviously something that can be optimized in a concrete protocol realization. Tom Taylor _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Mar 27 10:13:14 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 KAA02227 for ; Thu, 27 Mar 2003 10:13:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RFYYS24167 for midcom-archive@odin.ietf.org; Thu, 27 Mar 2003 10:34:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RFY6O24149; Thu, 27 Mar 2003 10:34:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RFUtO24015 for ; Thu, 27 Mar 2003 10:30:55 -0500 Received: from beta.jnpr.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01651 for ; Thu, 27 Mar 2003 10:09:03 -0500 (EST) Received: from pi-smtp.jnpr.net ([10.10.2.36]) by beta.jnpr.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 27 Mar 2003 07:11:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] On SNMPv3, clarification, invitation for discussion Date: Thu, 27 Mar 2003 10:11:24 -0500 Message-ID: Thread-Topic: [midcom] On SNMPv3, clarification, invitation for discussion Thread-Index: AcLzDeObqxWxxEtVRkKq7PKC4IrDZgBZFt5w From: "Jerome Moisand" To: "Tom Taylor" , X-OriginalArrivalTime: 27 Mar 2003 15:11:25.0418 (UTC) FILETIME=[225494A0:01C2F473] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2RFUtO24016 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: 8bit Quite true. It is a fact that the great majority of Service Providers (ILECs, PTTs, ISPs, MSOs, whatever) tend to refuse to use SNMP for anything else than monitoring (hence GETs). From my experience, this appears to be true for all market segments, and all geographical theaters. Could this trend be reversed by educating more & more people about SNMPv3 is a matter of endless debates... But this new IETF policy about 'writable MIBs' will definitely not help to address this 'deployability' issue. This is quite different from the enterprise environment where SNMP SETs are more commonly accepted. Jerome -----Original Message----- From: Tom Taylor [mailto:taylor@nortelnetworks.com] Sent: Tuesday, March 25, 2003 3:30 PM To: Melinda Shore; midcom@ietf.org Subject: Re: [midcom] On SNMPv3, clarification, invitation for discussion The real issue is deployability of a MIDCOM protocol. We heard that the operators we are targetting for MIDCOM are not enabling SNMP SET operations. Jonathan was saying this was on grounds of cost. Other interpretations are certainly possible. The point is that operators will enable a MIDCOM protocol only if they are convinced that they have adequate control over its operation, whether it be SNMPv3 or SIMCO. We need to hear from operators on what would convince them that the risks are acceptable, and that may well call for an extended risk analysis on our part. [...] Melinda Shore wrote: > At the midcom meeting last week David Harrington raised the > issue of a recent policy change in the OPS area, which is > that because the use of SNMP for configuration hasn't > accelerated as expected, the OPS area seems to be moving > towards XML for configuration (no protocol specified). > There's a new policy that writable MIBs are no longer > required. > > This raised the question of whether or not we want to continue > with SNMPv3 as the midcom protocol, and we had a lengthy > discussion about what the actual issues are. One thing to > consider is that the environment in which we expect midcom > to be deployed is substantially different from the > environment in which people might be using SNMP for static > device configuration. > > After the meeting I spent some time talking with Mary and > David, and they seem willing to continue the work (although > they'd appreciate more feedback from the working group). > The first draft of their work should be out very soon and we > expect that it won't take more than a few months to wrap it > up and deliver it to the IESG. While the future may indeed > turn out to be XMLCONF, 1) that working group isn't even > chartered yet, and 2) the group that's developing it is > using the same data model as SMIng, and there are compilers > that take a MIB and turn it into an XML document. That is > to say, MIB work now will be reusable with XMLCONF later. > > I attended the OPS area meeting where this information was > confirmed. It's not that SNMP is being deprecated or even > that the use of SNMP for configuration is being deprecated. > It's that writable MIBs are no longer mandatory. > > 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 mailnull@www1.ietf.org Thu Mar 27 10:49:53 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 KAA04569 for ; Thu, 27 Mar 2003 10:49:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RGBCW27812 for midcom-archive@odin.ietf.org; Thu, 27 Mar 2003 11:11:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RGACO27783; Thu, 27 Mar 2003 11:10:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RG3GO26705 for ; Thu, 27 Mar 2003 11:03:16 -0500 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04093 for ; Thu, 27 Mar 2003 10:41:26 -0500 (EST) 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.6/8.12.6) with ESMTP id h2RFhe9a023298 for ; Thu, 27 Mar 2003 07:43:41 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AFF46385; Thu, 27 Mar 2003 07:43:39 -0800 (PST) Message-Id: <200303271543.AFF46385@mira-sjc5-c.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Thu, 27 Mar 2003 10:43:38 -0500 Subject: [midcom] Semantics document, closing open items 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: , 1) The wildcarding proposal was uncontroversial at the meeting and appears to be uncontroversial here, so the consensus is clearly to allow wildcarding. 2) There was confusion about the two-step reservation process at the meeting and there's been little discussion about it here, so I'm not going to consider this resolved. The proposal is to have a two-step reservation process, with separate steps for requesting the reservation and enabling the reservations. Unless there are objections over the next several days, the proposal will stand as is. I hope the people who had issues with this at the meeting will speak up. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Mar 28 06:35:26 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 GAA24670 for ; Fri, 28 Mar 2003 06:35:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SBv9329066 for midcom-archive@odin.ietf.org; Fri, 28 Mar 2003 06:57:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SBrbO28948; Fri, 28 Mar 2003 06:53:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SBoZO28803 for ; Fri, 28 Mar 2003 06:50:35 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24480 for ; Fri, 28 Mar 2003 06:28:17 -0500 (EST) Received: by fox.iptel.org (Postfix, from userid 534) id 6E2E420F; Fri, 28 Mar 2003 12:30:36 +0100 (CET) Received: from jku07.fokus.fraunhofer.de (port-212-202-201-178.reverse.qdsl-home.de [212.202.201.178]) by fox.iptel.org (Postfix) with ESMTP id 708A51F7; Fri, 28 Mar 2003 12:30:35 +0100 (CET) Message-Id: <5.2.0.9.0.20030328121700.027c0b98@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Mar 2003 12:28:54 +0100 To: Melinda Shore , midcom@ietf.org From: Jiri Kuthan Subject: Re: [midcom] Semantics document, closing open items In-Reply-To: <200303271543.AFF46385@mira-sjc5-c.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-9.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO autolearn=ham version=2.51 X-Spam-Checker-Version: SpamAssassin 2.51 (1.174.2.5-2003-03-20-exp) 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: , I'm neither saying it's needed nor it's not. I'm just wondering if there is any argument WHY it's needed. The point is that primarily, the open-or-not decision is drawn from willingness of the party on the protected middlebox side. Making it additionaly depend on what the party on the other side thinks buys little additional security. That's the case with SIP, imho. If we split "get-NAT-translations-and-open- pinholes" in two phases, we just add a contraint "don't open if the public side user does not wish so". Are there scenarios which add more security through that? -Jiri At 04:43 PM 3/27/2003, Melinda Shore wrote: >2) There was confusion about the two-step reservation >process at the meeting and there's been little discussion >about it here, so I'm not going to consider this resolved. >The proposal is to have a two-step reservation process, with >separate steps for requesting the reservation and enabling >the reservations. Unless there are objections over the next >several days, the proposal will stand as is. I hope the >people who had issues with this at the meeting will speak >up. > >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 mailnull@www1.ietf.org Fri Mar 28 11:48:33 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 LAA06870 for ; Fri, 28 Mar 2003 11:48:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SHAOs21094 for midcom-archive@odin.ietf.org; Fri, 28 Mar 2003 12:10:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SH9sO21049; Fri, 28 Mar 2003 12:09:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SH54O20080 for ; Fri, 28 Mar 2003 12:05:04 -0500 Received: from smtp011.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06642 for ; Fri, 28 Mar 2003 11:42:42 -0500 (EST) Received: from 12-234-140-126.client.attbi.com (HELO suresh) (srisuresh@12.234.140.126 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 28 Mar 2003 16:45:03 -0000 Reply-To: From: "Pyda Srisuresh" To: "Eliot Lear" Cc: Subject: RE: [midcom] On SNMPv3, clarification, invitation for discussion Date: Fri, 28 Mar 2003 08:45:02 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <3E7F9B4B.1020303@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal 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 I agree. I believe, XMLCONF is useful for one-time configuration/retrieval. SNMP is still desirable for dynamic transactions. cheers, suresh > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Eliot Lear > Sent: Monday, March 24, 2003 3:57 PM > To: Melinda Shore > Cc: midcom@ietf.org > Subject: Re: [midcom] On SNMPv3, clarification, invitation for > discussion > > > Melinda, > > Two more additions to your valid comments. > > XMLCONF has an intended audience: configuration and retrieval of static > information within devices. This may be slightly imprecise, but let me > tell you what we *don't* think XMLCONF is good for: exchange of protocol > state information. We wouldn't want to replace BGP with XMLCONF, for > example. > > I believe midcom comes a lot closer to a state exchange protocol, such > as BGP, then it does to the screen scraping that we are attempting to > address with NET-CONF. Certainly this holds true for STUN, and that's a > good hint, IMHO. > > ALSO. To repeat what Bert, Andy, and others have said, while the > requirement has been relaxed, there is nothing stopping anyone from > writing a MIB or specification with writable objects. You simply aren't > REQUIRED to do so. > > If this group believes that SNMP with writable objects is the right way > to go, I say go for it. > > Eliot > > _______________________________________________ > 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 mailnull@www1.ietf.org Fri Mar 28 12:02:44 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 MAA07804 for ; Fri, 28 Mar 2003 12:02:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SHOa422184 for midcom-archive@odin.ietf.org; Fri, 28 Mar 2003 12:24:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SHO6O22135; Fri, 28 Mar 2003 12:24:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SHLgO22055 for ; Fri, 28 Mar 2003 12:21:42 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07576 for ; Fri, 28 Mar 2003 11:59:19 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h2SH1dBd006632; Fri, 28 Mar 2003 12:01:39 -0500 (EST) Message-ID: <3E847FEE.7020106@dynamicsoft.com> Date: Fri, 28 Mar 2003 12:01:34 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: srisuresh@yahoo.com CC: Eliot Lear , midcom@ietf.org Subject: Re: [midcom] On SNMPv3, clarification, invitation for discussion References: 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 Pyda, This is a pretty substantial claim. Can you provide details on why this is true? -Jonathan R. Pyda Srisuresh wrote: > I agree. I believe, XMLCONF is useful for one-time configuration/retrieval. > SNMP is still desirable for > dynamic transactions. > > cheers, > suresh > > >>-----Original Message----- >>From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of >>Eliot Lear >>Sent: Monday, March 24, 2003 3:57 PM >>To: Melinda Shore >>Cc: midcom@ietf.org >>Subject: Re: [midcom] On SNMPv3, clarification, invitation for >>discussion >> >> >>Melinda, >> >>Two more additions to your valid comments. >> >>XMLCONF has an intended audience: configuration and retrieval of static >>information within devices. This may be slightly imprecise, but let me >>tell you what we *don't* think XMLCONF is good for: exchange of protocol >>state information. We wouldn't want to replace BGP with XMLCONF, for >>example. >> >>I believe midcom comes a lot closer to a state exchange protocol, such >>as BGP, then it does to the screen scraping that we are attempting to >>address with NET-CONF. Certainly this holds true for STUN, and that's a >>good hint, IMHO. >> >>ALSO. To repeat what Bert, Andy, and others have said, while the >>requirement has been relaxed, there is nothing stopping anyone from >>writing a MIB or specification with writable objects. You simply aren't >>REQUIRED to do so. >> >>If this group believes that SNMP with writable objects is the right way >>to go, I say go for it. >> >>Eliot >> >>_______________________________________________ >>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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 mailnull@www1.ietf.org Fri Mar 28 13:22:31 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 NAA10779 for ; Fri, 28 Mar 2003 13:22:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SIiNZ28669 for midcom-archive@odin.ietf.org; Fri, 28 Mar 2003 13:44:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SIakO27431; Fri, 28 Mar 2003 13:36:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SIUxO27095 for ; Fri, 28 Mar 2003 13:30:59 -0500 Received: from hermes.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10332 for ; Fri, 28 Mar 2003 13:08:34 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h2SI7IY06335 for ; Fri, 28 Mar 2003 18:07:18 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h2SI50e23900 for ; Fri, 28 Mar 2003 18:05:02 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003032810082410108 ; Fri, 28 Mar 2003 10:08:24 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Mar 2003 10:10:47 -0800 Message-ID: From: "Durham, David" To: Jonathan Rosenberg , srisuresh@yahoo.com Cc: Eliot Lear , midcom@ietf.org Subject: RE: [midcom] On SNMPv3, clarification, invitation for discussion Date: Fri, 28 Mar 2003 10:10:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" 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: , I agree. There is nothing technically preventing XMLConf from doing small dynamic transactions. In fact, I argue that XMLConf would be superior over SNMP for such transactions. Do the math: * snmp's unreliable transport means get followed by set followed by get. Several round trip latencies incurred by each snmp get set get exchange. RTT becomes the most significant bottleneck for snmp. Pray there's no packet loss. * snmp's udp transport has no flow control, fairly easy to perform DoS attack either on purpose or quite accidentally. * snmpv3 has a very complicated user security model. Few people using it to date. Many operators today typically run snmpv1 over VLANs or VPNs. * A complete Oid is exchanged with every attribute being communicated making each snmp BER transaction just as big if not bigger than equivalent XML encoded data. * BER encoding rules sufficiently complex that recently many snmp deployments have been found susceptible to buffer overflow attacks allowing attackers to crash systems or launch worms. We can only assume all the holes have now been plugged. * Rowstatus is the best transactional mechanism snmp has. Need I say more? Okay, I will: get rowstatus, set rowstatus, check rowstatus, get first attribute, set first attribute, get first attribute, get second