From mailnull@www1.ietf.org Fri Nov 1 08:48:19 2002 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 IAA06795 for ; Fri, 1 Nov 2002 08:48:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1DoGI25100 for midcom-archive@odin.ietf.org; Fri, 1 Nov 2002 08:50:16 -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 gA1Dkdv24834; Fri, 1 Nov 2002 08:46:42 -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 gA1Djbv24703 for ; Fri, 1 Nov 2002 08:45:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06380; Fri, 1 Nov 2002 08:43:09 -0500 (EST) Message-Id: <200211011343.IAA06380@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 01 Nov 2002 08:43:09 -0500 Subject: [midcom] I-D ACTION:draft-ietf-midcom-semantics-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. 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-00.txt Pages : 55 Date : 2002-10-31 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-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-semantics-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-semantics-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-31150424.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-semantics-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-semantics-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-31150424.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Nov 1 12:26:52 2002 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 MAA24018 for ; Fri, 1 Nov 2002 12:26:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1HSo103329 for midcom-archive@odin.ietf.org; Fri, 1 Nov 2002 12:28:50 -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 gA1HPAv01813; Fri, 1 Nov 2002 12:25:10 -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 gA1HOHv01668 for ; Fri, 1 Nov 2002 12:24: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 MAA23569; Fri, 1 Nov 2002 12:21:47 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gA1HOBY44330; Fri, 1 Nov 2002 18:24:12 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] (unknown [192.168.102.31]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 0AFE273366; Fri, 1 Nov 2002 18:23:52 +0100 (CET) Date: Fri, 01 Nov 2002 18:23:49 +0100 From: Juergen Quittek To: Internet-Drafts@ietf.org, IETF-Announce@ccrle.nec.de Cc: midcom@ietf.org Subject: Re: [midcom] I-D ACTION:draft-ietf-midcom-semantics-00.txt Message-ID: <4384033.1036175028@[192.168.102.31]> In-Reply-To: <200211011343.IAA06380@ietf.org> References: <200211011343.IAA06380@ietf.org> 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 Dear all, The announced document is based on draft-stiemerling-midcom-semantics-02.txt and contains a lot of improvements by Tom. It describes the semantics of a midcom protocol meeting the requirements, but it is still open to the selection of a Midcom protocol. All four protocol candidates can implement this semantics. The semantics is structured into three groups of transactions: session control transactions, policy rule transactions, and policy rule group transactions. For each of the transaction groups, a very simple state machine is defined. A concrete protocol will probably extend the number of states, the number of transactions, and/or the number of parameters for some transactions. But Regardless of such extensions, the semantics provide the minimum necessary subset of what must be implemented. After describing the the semantics, conformance statements for implementations are given. These statemets cover conformance with the semantics. A concrete protocol will need to extend them by by protocol specific statements. Two usage example covering many of the transaction illustrate the use of a protocol based on this semantics. Finally, compliancy of the semantics with the Midcom requirements is explained for each individual requirement. Tom, Martin, and I see three major areas where the document needs improvement: - The group transactions need to be re-designed. They are based on the assumption that groups can be instatiated independent of policy rules. This is different to the result of our WG discussion at Yokohama (no groups timers!). We want to simplify the group concept by only having logical groups that are implicitly instanciated by policy rule transactions. All three of us agree on this, but becasue time was lacking to apply all required changes consistently to the document, we did not start this work. We see this as a major subject of change for the next version. - We also did not have sufficient time for developing the wildcarding semantics thoroughly. We believe that the current one is not mature and probably needs improvement. - The major configuration of firewalls and NATs is covered by two transactions: the optional policy reserve rule transaction (PRR) and the mandatory policy enable rule transaction (PER). PER handles all configuration concerning packet treatment at the middlebox. PRR is only rerquired in some cases, when an agent needs to reserve addresses and port numbers at the middlebox, before it can enter a PER transaction. We are still discussing, to what extend the PER transaction should perform reservations. Further subjects of potential improvement are listed at the end of the document in the Open Issues section. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- Internet-Drafts@ietf.org wrote on 01 November 2002 08:43 -0500: > 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-00.txt > Pages : 55 > Date : 2002-10-31 > > 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-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-midcom-semantics-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-midcom-semantics-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sat Nov 2 16:37:32 2002 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 QAA12970 for ; Sat, 2 Nov 2002 16:37:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA2LdVO22124 for midcom-archive@odin.ietf.org; Sat, 2 Nov 2002 16:39: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 gA2Lcwv22079; Sat, 2 Nov 2002 16:38:58 -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 gA2LY3v21330 for ; Sat, 2 Nov 2002 16:34:03 -0500 Received: from IPOfCard1.guest-tek.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12759 for ; Sat, 2 Nov 2002 16:31:31 -0500 (EST) Received: from dynamicsoft.com ([141.154.107.210]) by IPOfCard1.guest-tek.com (8.11.6/8.8.7) with ESMTP id gA2LWZr13362; Sat, 2 Nov 2002 16:32:35 -0500 Message-ID: <3DC42C27.4020502@dynamicsoft.com> Date: Sat, 02 Nov 2002 14:48:55 -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: "Panayiotis A. Thermos" CC: midcom@ietf.org Subject: Re: [midcom] STUN-obtaining a Shared Secret- Verbiage 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 My apologies for the delay in responding. You are correct. IN fact, this is one of the changes since -03. The second paragraph now reads: First, the client determines the IP address and port that it will open a TCP connection to. This is done using the discovery procedures in Section 9.1. The client opens up the connection to that address and port, and immediately begins TLS negotiation [2]. The client MUST verify the identity of the server. To do that, it follows the identification procedures defined in Section 3.1 of RFC 2818 [6]. Those procedures assume the client is derefencing a URI. For purposes of usage with this specification, the client treats the domain name or IP address used in Section 9.1 as the host portion of the URI that has been dereferenced. -Jonathan R. Panayiotis A. Thermos wrote: > Section 9.2 page 16 of draft-ietf-midcom-stun-02.txt paragraph 2, > states "The client MUST authorize the server". > > Authorization is associated with privileges and ability to perform > a specific task based on your access profile. > I do not see why the STUN client should be required to > "authorize" any server responses. > > I believe the author(s) in this case mean "Authenticate" > or "Verify" the server's response. > > So the sentence should read, > "The client MUST authenticate the server." > > If I miss something please let me know. > > Peter T. > > _______________________________________________ > 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 Mon Nov 4 09:15:09 2002 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 JAA13605 for ; Mon, 4 Nov 2002 09:15:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4EH8u27811 for midcom-archive@odin.ietf.org; Mon, 4 Nov 2002 09:17:08 -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 gA4EDEv27632; Mon, 4 Nov 2002 09:13:14 -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 gA4E8Lv27474 for ; Mon, 4 Nov 2002 09:08:21 -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 JAA13253 for ; Mon, 4 Nov 2002 09:05:51 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gA4E8IY15969; Mon, 4 Nov 2002 15:08:18 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 57EF95F395; Mon, 4 Nov 2002 15:07:51 +0100 (CET) Message-ID: <3DC67ED7.1060205@ccrle.nec.de> Date: Mon, 04 Nov 2002 15:06:15 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE MIME-Version: 1.0 To: Martin Stiemerling Cc: midcom@ietf.org Subject: Re: [midcom] COPS in the eval document References: <200210302042.AAL28264@mira-sjc5-4.cisco.com> <3DC20991.9010002@ccrle.nec.de> 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 I have agreed in the email below, but I'm not sure on what we exactly have agreed (not enough sleep). In my opinion we can keep the text in 2.1.1 , but we haven't agree on the actual topic: In the partial met of the directional component in reality a failed, or to say it in other words, is this a big problem or not. The last has been originally my question. This hasn't answered so far. Martin Martin Stiemerling wrote: > I agree as well! > > Melinda Shore wrote: > >> I'd like to propose that we let the existing text in 2.1.1 >> stand as is. >> 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 Mon Nov 4 10:50:43 2002 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 KAA19010 for ; Mon, 4 Nov 2002 10:50:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4FqhH01910 for midcom-archive@odin.ietf.org; Mon, 4 Nov 2002 10:52:43 -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 gA4FnBv01788; Mon, 4 Nov 2002 10:49:11 -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 gA4FmKv01731 for ; Mon, 4 Nov 2002 10:48:20 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18767 for ; Mon, 4 Nov 2002 10:45:49 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA4FmGPP018968 for ; Mon, 4 Nov 2002 07:48:16 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAQ89947; Mon, 4 Nov 2002 07:43:31 -0800 (PST) Message-Id: <200211041543.AAQ89947@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Mon, 04 Nov 2002 10:48:15 -0500 Subject: [midcom] Straw poll 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 a little concerned that we've only gotten ->1<- response to a straw poll which seems to me to be central to the working group's interests. If possible I'd like to get some more feedback on the questions, and I'm also curious about the low response level - are people busy with other stuff? Were the questions badly-phrased or inappropriate? Etc. I'd really like to keep the working group moving forward. The question of protocol selection is necessarily contentious and political, and if there are process problems it would be a big help to me if those could be pointed out so that they could be addressed and fixed. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Nov 4 11:00:41 2002 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 LAA19473 for ; Mon, 4 Nov 2002 11:00:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4G2fY02451 for midcom-archive@odin.ietf.org; Mon, 4 Nov 2002 11:02: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 gA4FxBv02213; Mon, 4 Nov 2002 10:59:11 -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 gA4FvAv02061 for ; Mon, 4 Nov 2002 10:57: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 KAA19218 for ; Mon, 4 Nov 2002 10:54:39 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA4Fuvc18266; Mon, 4 Nov 2002 10:56:57 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Nov 2002 10:56:58 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400DEA8@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] Straw poll Date: Mon, 4 Nov 2002 10:56:48 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) 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: , In my mind the issue is fairly simple: none of the alternatives in front of us is realistic. SNMPv3 and DIAMETER have the best fit, but little chance of widespread deployment in the devices concerned. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Monday, November 04, 2002 10:48 AM > To: midcom@ietf.org > Subject: [midcom] Straw poll > > > I'm a little concerned that we've only gotten ->1<- response > to a straw poll which seems to me to be central to the > working group's interests. If possible I'd like to get some > more feedback on the questions, and I'm also curious about > the low response level - are people busy with other stuff? > Were the questions badly-phrased or inappropriate? Etc. > > I'd really like to keep the working group moving forward. > The question of protocol selection is necessarily > contentious and political, and if there are process problems > it would be a big help to me if those could be pointed out > so that they could be addressed and fixed. > > 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 Mon Nov 4 11:06:46 2002 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 LAA19790 for ; Mon, 4 Nov 2002 11:06:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4G8k903243 for midcom-archive@odin.ietf.org; Mon, 4 Nov 2002 11:08: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 gA4G58v02563; Mon, 4 Nov 2002 11:05: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 gA4G4wv02536 for ; Mon, 4 Nov 2002 11:04:58 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19552 for ; Mon, 4 Nov 2002 11:02:27 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA4G4x306322; Mon, 4 Nov 2002 10:04:59 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Nov 2002 10:04:46 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CA66@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Martin Stiemerling'" Cc: midcom@ietf.org Subject: RE: [midcom] COPS in the eval document Date: Mon, 4 Nov 2002 10:04:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2841B.E23BD2B0" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2841B.E23BD2B0 Content-Type: text/plain; charset="iso-8859-1" Martin, I think we finished the debate on your particular point a while back. It's P (and not F) because there is a reasonable proposal on how the issue can be dealt with by the protocol), and that's consistent with how we dealt with similar issues for the other protocols. Whether that's a big problem or little problem seems to be quite subjective, however, the sense I got from Kwok's responses was that it's not a big problem. Mary. -----Original Message----- From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] Sent: Monday, November 04, 2002 8:06 AM To: Martin Stiemerling Cc: midcom@ietf.org Subject: Re: [midcom] COPS in the eval document I have agreed in the email below, but I'm not sure on what we exactly have agreed (not enough sleep). In my opinion we can keep the text in 2.1.1 , but we haven't agree on the actual topic: In the partial met of the directional component in reality a failed, or to say it in other words, is this a big problem or not. The last has been originally my question. This hasn't answered so far. Martin Martin Stiemerling wrote: > I agree as well! > > Melinda Shore wrote: > >> I'd like to propose that we let the existing text in 2.1.1 >> stand as is. >> 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 ------_=_NextPart_001_01C2841B.E23BD2B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] COPS in the eval document

Martin,

I think we finished the debate on your particular = point a while back. It's P (and not F) because there is a reasonable = proposal on how the issue can be dealt with by the protocol), and = that's consistent with how we dealt with similar issues for the other = protocols.  Whether that's a big problem or little problem seems = to be quite subjective, however, the sense I got from Kwok's responses = was that it's not a big problem. 

Mary.

-----Original Message-----
From: Martin Stiemerling [mailto:Martin.Stiemerlin= g@ccrle.nec.de]
Sent: Monday, November 04, 2002 8:06 AM
To: Martin Stiemerling
Cc: midcom@ietf.org
Subject: Re: [midcom] COPS in the eval = document


I have agreed in the email below, but I'm not sure on = what we exactly
have agreed (not enough sleep). In my opinion we can = keep the text in
2.1.1 , but we haven't agree on the actual topic: In = the partial met of
the directional component in reality a failed, or to = say it in other
words, is this a big problem or not. The last has = been originally my
question. This hasn't answered so far.

Martin

Martin Stiemerling wrote:

> I agree as well!
>
> Melinda Shore wrote:
>
>> I'd like to propose that we let the = existing text in 2.1.1
>> stand as is.
>> 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

------_=_NextPart_001_01C2841B.E23BD2B0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 5 06:17:55 2002 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 GAA11933 for ; Tue, 5 Nov 2002 06:17:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5BJs701700 for midcom-archive@odin.ietf.org; Tue, 5 Nov 2002 06:19: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 gA5BGIv01352; Tue, 5 Nov 2002 06:16: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 gA5BALv00857 for ; Tue, 5 Nov 2002 06:10:21 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10613; Tue, 5 Nov 2002 06:07:51 -0500 (EST) Message-Id: <200211051107.GAA10613@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 05 Nov 2002 06:07:50 -0500 Subject: [midcom] I-D ACTION:draft-stiemerling-midcom-simco-02.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simple Middlebox Configuration (SIMCO) Protocol Version 2.0 Author(s) : M. Stiemerling, J. Quittek Filename : draft-stiemerling-midcom-simco-02.txt Pages : 20 Date : 2002-11-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-02.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-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-stiemerling-midcom-simco-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-4171844.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-stiemerling-midcom-simco-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-stiemerling-midcom-simco-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-4171844.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 5 09:07:58 2002 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 JAA19174 for ; Tue, 5 Nov 2002 09:07:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5E9v013699 for midcom-archive@odin.ietf.org; Tue, 5 Nov 2002 09:09:57 -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 gA5E9Kv13626; Tue, 5 Nov 2002 09:09:20 -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 gA5Dxxv12678 for ; Tue, 5 Nov 2002 08:59:59 -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 IAA18758 for ; Tue, 5 Nov 2002 08:57:28 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gA5DxtY62446; Tue, 5 Nov 2002 14:59:55 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 54F97671FA; Tue, 5 Nov 2002 14:59:24 +0100 (CET) Message-ID: <3DC7CEA8.7030908@ccrle.nec.de> Date: Tue, 05 Nov 2002 14:59:04 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE MIME-Version: 1.0 To: Mary Barnes Cc: midcom@ietf.org Subject: Re: [midcom] COPS in the eval document References: <1B54FA3A2709D51195C800508BF9386A05A7CA66@zrc2c000.us.nortel.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 Mary, Mary Barnes wrote: > Martin, > > I think we finished the debate on your particular point a while back. > It's P (and not F) because there is a reasonable proposal on how the > issue can be dealt with by the protocol), and that's consistent with how That's true, we agreed on a P in the document. But since this is an ongoing discussion my question was in the sense wether the working group feels that this P is enough for having COPS as MIDCOM protocol or not. This question hasn't find a satisfied answer up to now. > we dealt with similar issues for the other protocols. Whether that's a > big problem or little problem seems to be quite subjective, however, the > sense I got from Kwok's responses was that it's not a big problem. > > Mary. > > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: Monday, November 04, 2002 8:06 AM > To: Martin Stiemerling > Cc: midcom@ietf.org > Subject: Re: [midcom] COPS in the eval document > > > I have agreed in the email below, but I'm not sure on what we exactly > have agreed (not enough sleep). In my opinion we can keep the text in > 2.1.1 , but we haven't agree on the actual topic: In the partial met of > the directional component in reality a failed, or to say it in other > words, is this a big problem or not. The last has been originally my > question. This hasn't answered so far. > > Martin > > Martin Stiemerling wrote: > > > I agree as well! > > > > Melinda Shore wrote: > > > >> I'd like to propose that we let the existing text in 2.1.1 > >> stand as is. > >> 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 > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 5 09:11:36 2002 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 JAA19368 for ; Tue, 5 Nov 2002 09:11:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5EDZl13927 for midcom-archive@odin.ietf.org; Tue, 5 Nov 2002 09:13:35 -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 gA5EDDv13915; Tue, 5 Nov 2002 09:13: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 gA5ECdv13884 for ; Tue, 5 Nov 2002 09:12:39 -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 JAA19326 for ; Tue, 5 Nov 2002 09:10:08 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gA5ECPY63164; Tue, 5 Nov 2002 15:12:25 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 37C195609F; Tue, 5 Nov 2002 15:11:54 +0100 (CET) Message-ID: <3DC7D17F.6070704@ccrle.nec.de> Date: Tue, 05 Nov 2002 15:11:11 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE MIME-Version: 1.0 To: Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] Straw poll References: <200211041543.AAQ89947@mira-sjc5-4.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 Shore wrote: > I'm a little concerned that we've only gotten ->1<- response > to a straw poll which seems to me to be central to the > working group's interests. If possible I'd like to get some > more feedback on the questions, and I'm also curious about > the low response level - are people busy with other stuff? This decision (or these decisions) require som reading, understanding and evaluation so this takes some time. > Were the questions badly-phrased or inappropriate? Etc. Well phrased! From my point of view COPS (-PR) seems not be suitable, since: - It does not met (IMHO) the directional requirement as discussed in the last emails - The COPS PEP is not able to receive configuration data from multiple PDP for the *same* resource, e.g. the middlebox can not receive policy rule configuration requests from different agents for the same packet filter at the same time. MEGACO doesn't met the directional requirement as well. SNMP does met a lot of requirements, but I still have my doubts, since nobody or only a few people uses SNMP for configuration of devices. For diameter I'm still in reading the draft. Martin > > I'd really like to keep the working group moving forward. > The question of protocol selection is necessarily > contentious and political, and if there are process problems > it would be a big help to me if those could be pointed out > so that they could be addressed and fixed. > > 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 Tue Nov 5 10:29:47 2002 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 KAA23583 for ; Tue, 5 Nov 2002 10:29:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5FVl819374 for midcom-archive@odin.ietf.org; Tue, 5 Nov 2002 10:31: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 gA5FSDv19165; Tue, 5 Nov 2002 10:28: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 gA5FRmv19118 for ; Tue, 5 Nov 2002 10:27:48 -0500 Received: from pmesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23375 for ; Tue, 5 Nov 2002 10:25:17 -0500 (EST) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0H540009T09IV9@firewall.wcom.com> for midcom@ietf.org; Tue, 05 Nov 2002 15:27:19 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H5400401095DR@pmismtp02.wcomnet.com>; Tue, 05 Nov 2002 15:27:18 +0000 (GMT) Received: from ws041v4569 ([166.42.33.176]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H54001U309EDL@pmismtp02.wcomnet.com>; Tue, 05 Nov 2002 15:27:14 +0000 (GMT) Date: Tue, 05 Nov 2002 09:27:16 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] Straw poll In-reply-to: <3DC7D17F.6070704@ccrle.nec.de> To: "'Martin Stiemerling'" , "'Melinda Shore'" Cc: midcom@ietf.org Message-id: <003c01c284df$d2c51520$91a023a6@ws041v4569> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-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 with Martin, but have less reservations about snmp, though not typiclly associated with configuration of elements that potentially are used to enforce security/access policies, in v3 may offer a potential solution. It may be that additional external protocols may be required to reduce the risk factor (such as IPSec). More reading is something that I am still in the process of as well. Chris -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Martin Stiemerling Sent: Tuesday, November 05, 2002 8:11 AM To: Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] Straw poll Melinda Shore wrote: > I'm a little concerned that we've only gotten ->1<- response to a > straw poll which seems to me to be central to the working group's > interests. If possible I'd like to get some more feedback on the > questions, and I'm also curious about the low response level - are > people busy with other stuff? This decision (or these decisions) require som reading, understanding and evaluation so this takes some time. > Were the questions badly-phrased or inappropriate? Etc. Well phrased! From my point of view COPS (-PR) seems not be suitable, since: - It does not met (IMHO) the directional requirement as discussed in the last emails - The COPS PEP is not able to receive configuration data from multiple PDP for the *same* resource, e.g. the middlebox can not receive policy rule configuration requests from different agents for the same packet filter at the same time. MEGACO doesn't met the directional requirement as well. SNMP does met a lot of requirements, but I still have my doubts, since nobody or only a few people uses SNMP for configuration of devices. For diameter I'm still in reading the draft. Martin > > I'd really like to keep the working group moving forward. > The question of protocol selection is necessarily > contentious and political, and if there are process problems it would > be a big help to me if those could be pointed out so that they could > be addressed and fixed. > > 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 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 5 12:40:04 2002 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 MAA01127 for ; Tue, 5 Nov 2002 12:40:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5Hg4m29774 for midcom-archive@odin.ietf.org; Tue, 5 Nov 2002 12:42: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 gA5HcOv29618; Tue, 5 Nov 2002 12:38:24 -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 gA5HbQv29547 for ; Tue, 5 Nov 2002 12:37:26 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00919 for ; Tue, 5 Nov 2002 12:34:53 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA5Haxv05623; Tue, 5 Nov 2002 12:36:59 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 12:36:59 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C04388068@zcard031.ca.nortel.com> From: "Louis-Nicolas Hamer" To: "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] Straw poll Date: Tue, 5 Nov 2002 12:36:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C284F1.EC982958" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C284F1.EC982958 Content-Type: text/plain I think Diameter is not a good fit, I would remove it from the list of potential protocols. It is way to bulky for midcom. I do think COPS, MEGACO & SNMP are very good fits. cheers, L-N > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Monday, November 04, 2002 10:48 AM > To: midcom@ietf.org > Subject: [midcom] Straw poll > > > I'm a little concerned that we've only gotten ->1<- response > to a straw poll which seems to me to be central to the > working group's interests. If possible I'd like to get some > more feedback on the questions, and I'm also curious about > the low response level - are people busy with other stuff? > Were the questions badly-phrased or inappropriate? Etc. > > I'd really like to keep the working group moving forward. > The question of protocol selection is necessarily > contentious and political, and if there are process problems > it would be a big help to me if those could be pointed out > so that they could be addressed and fixed. > > Thanks, > > Melinda > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C284F1.EC982958 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [midcom] Straw poll

I think Diameter is not a good fit, I would remove it = from the list of potential protocols.
It is way to bulky for midcom.

I do think COPS, MEGACO & SNMP are very good = fits.

cheers,
L-N

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Monday, November 04, 2002 10:48 AM
> To: midcom@ietf.org
> Subject: [midcom] Straw poll
>
>
> I'm a little concerned that we've only gotten = ->1<- response
> to a straw poll which seems to me to be central = to the
> working group's interests.  If possible = I'd like to get some
> more feedback on the questions, and I'm also = curious about
> the low response level - are people busy with = other stuff?
> Were the questions badly-phrased or = inappropriate?  Etc. 
>
> I'd really like to keep the working group = moving forward.
> The question of protocol selection is = necessarily
> contentious and political, and if there are = process problems
> it would be a big help to me if those could be = pointed out
> so that they could be addressed and = fixed.
>
> Thanks,
>
> Melinda
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C284F1.EC982958-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Nov 6 09:57:38 2002 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 JAA24142 for ; Wed, 6 Nov 2002 09:57:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6Exc118212 for midcom-archive@odin.ietf.org; Wed, 6 Nov 2002 09:59: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 gA6Eqjv17814; Wed, 6 Nov 2002 09:52: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 gA6EpCv17753 for ; Wed, 6 Nov 2002 09:51:12 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23514 for ; Wed, 6 Nov 2002 09:48:41 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gA6Ep8ot018685 for ; Wed, 6 Nov 2002 06:51:08 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAR69158; Wed, 6 Nov 2002 06:46:24 -0800 (PST) Message-Id: <200211061446.AAR69158@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Wed, 06 Nov 2002 09:51:07 -0500 Subject: [midcom] Text conferencing during meeting 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: , As the meeting draws closer and people's travel plans are firming up (or falling apart), I thought I'd check again to see if there's any interest in text conferencing among people who will not be able to attend the session but who will want to participate remotely. It would work as follows: a jabber server is being provided to the IETF, and we would be given a "conference room." A hearty and nimble-fingered volunteer would type in a running commentary, preferably without editorial observations, and participants can type in questions which would be read during question periods at the mike. Because of the need for a volunteer scribe (on top of the need for a volunteer minutes-taker) I would prefer to go ahead with this experiment only if we know that there will be people participating. We will be meeting on Tuesday, 18 November from 1415-1515. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Nov 6 14:13:43 2002 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 OAA07584 for ; Wed, 6 Nov 2002 14:13:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6JFjk05009 for midcom-archive@odin.ietf.org; Wed, 6 Nov 2002 14:15: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 gA6JFCv04997; Wed, 6 Nov 2002 14:15: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 gA6JEpv04956 for ; Wed, 6 Nov 2002 14:14:51 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07558 for ; Wed, 6 Nov 2002 14:12:18 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gA6JEcxF020283 for ; Wed, 6 Nov 2002 11:14:38 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAR79286; Wed, 6 Nov 2002 11:10:00 -0800 (PST) Message-Id: <200211061910.AAR79286@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Wed, 06 Nov 2002 14:14:43 -0500 Subject: [midcom] First draft of agenda for IETF 55 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: , Here's a first draft of the agenda for the session at the upcoming IETF meeting. Please let me know about omissions, additions, etc. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Nov 6 14:25:29 2002 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 OAA08124 for ; Wed, 6 Nov 2002 14:25:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6JRV005467 for midcom-archive@odin.ietf.org; Wed, 6 Nov 2002 14:27: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 gA6JR6v05442; Wed, 6 Nov 2002 14:27: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 gA6JQIv05392 for ; Wed, 6 Nov 2002 14:26:18 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08078 for ; Wed, 6 Nov 2002 14:23:45 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gA6JQ5xF029403 for ; Wed, 6 Nov 2002 11:26:05 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAR79937; Wed, 6 Nov 2002 11:21:29 -0800 (PST) Message-Id: <200211061921.AAR79937@mira-sjc5-4.cisco.com> cc: midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] First draft of agenda for IETF 55 In-Reply-To: Message from Melinda Shore of "Wed, 06 Nov 2002 14:14:43 EST." <200211061910.AAR79286@mira-sjc5-4.cisco.com> Date: Wed, 06 Nov 2002 14:26:10 -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: , D'oh! Here's the agenda - sorry for not appending the first go 'round. Melinda Middlebox Communication WG (midcom) Tuesday, November 18 at 14:15-15:15 =============================== CHAIR: Melinda Shore AGENDA: 5 min. Agenda-bashing 10 min. Status update Pre-midcom Protocol evaluation 20 min. Midcom protocol semantics draft-ietf-midcom-semantics-00.txt 10 min. Midcom protocol evaluation draft-ietf-midcom-protocol-eval-05.txt 15 min. Midcom protocol selection/process _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Nov 7 15:44:35 2002 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 PAA11392 for ; Thu, 7 Nov 2002 15:44:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7Kkcr17949 for midcom-archive@odin.ietf.org; Thu, 7 Nov 2002 15:46: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 gA7Kgkv17476; Thu, 7 Nov 2002 15:42: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 gA7KZ3v15470 for ; Thu, 7 Nov 2002 15:35:03 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST) Message-Id: <200211072011.PAA08965@ietf.org> From: The IESG To: All IETF Working Groups: ; x-msg: NoteWell Date: Thu, 07 Nov 2002 15:11:40 -0500 Subject: [midcom] Note Well Statement 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: , From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Nov 8 14:31:54 2002 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 OAA09569 for ; Fri, 8 Nov 2002 14:31:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8JXxF23740 for midcom-archive@odin.ietf.org; Fri, 8 Nov 2002 14:33:59 -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 gA8JTDv23524; Fri, 8 Nov 2002 14:29: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 gA8JSbv23501 for ; Fri, 8 Nov 2002 14:28:37 -0500 Received: from mail4.microsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09385 for ; Fri, 8 Nov 2002 14:26:00 -0500 (EST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 8 Nov 2002 11:28:31 -0800 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 08 Nov 2002 11:28:30 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 8 Nov 2002 11:28:29 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 8 Nov 2002 11:28:29 -0800 Received: from WIN-MSG-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Fri, 8 Nov 2002 11:28:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: [midcom] Straw poll Date: Fri, 8 Nov 2002 11:28:29 -0800 Message-ID: Thread-Topic: [midcom] Straw poll thread-index: AcKE8yqGuxgyjA3xQMqt8odhhwaZAABnkzqw From: "Christian Huitema" To: "Louis-Nicolas Hamer" , "Melinda Shore" , X-OriginalArrivalTime: 08 Nov 2002 19:28:37.0588 (UTC) FILETIME=[09339940:01C2875D] Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2875D.0439F8FA" ------_=_NextPart_001_01C2875D.0439F8FA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Question 1: I don't believe Megaco is a good fit. It is a specialized protocol, with a relatively large footprint. It is also a very new protocol, which really has only one domain of application so far. =20 I have some doubts about Diameter, mostly due to the fact that the IETF has still not finished standardizing it. I would wait for Diameter to get usage in its main application domain, a Radius replacement, before extending it to other domains. =20 Question 2: Of the remaining alternatives, SNMPv3 makes the most sense: it is the most likely to be already required in all platforms that will be engaged in MIDCOM. =20 Failing that, my preference would be for a light weight XML based protocol. =20 -----Original Message----- From: Louis-Nicolas Hamer [mailto:nhamer@nortelnetworks.com]=20 Sent: Tuesday, November 05, 2002 9:37 AM To: 'Melinda Shore'; midcom@ietf.org Subject: RE: [midcom] Straw poll =20 I think Diameter is not a good fit, I would remove it from the list of potential protocols.=20 It is way to bulky for midcom.=20 I do think COPS, MEGACO & SNMP are very good fits.=20 cheers,=20 L-N=20 > -----Original Message-----=20 > From: Melinda Shore [mailto:mshore@cisco.com]=20 > Sent: Monday, November 04, 2002 10:48 AM=20 > To: midcom@ietf.org=20 > Subject: [midcom] Straw poll=20 >=20 >=20 > I'm a little concerned that we've only gotten ->1<- response=20 > to a straw poll which seems to me to be central to the=20 > working group's interests. If possible I'd like to get some=20 > more feedback on the questions, and I'm also curious about=20 > the low response level - are people busy with other stuff?=20 > Were the questions badly-phrased or inappropriate? Etc. =20 >=20 > I'd really like to keep the working group moving forward.=20 > The question of protocol selection is necessarily=20 > contentious and political, and if there are process problems=20 > it would be a big help to me if those could be pointed out=20 > so that they could be addressed and fixed.=20 >=20 > Thanks,=20 >=20 > Melinda=20 > _______________________________________________=20 > midcom mailing list=20 > midcom@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/midcom=20 >=20 ------_=_NextPart_001_01C2875D.0439F8FA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [midcom] Straw poll

Question 1:

I don’t believe Megaco is a = good fit. It is a specialized protocol, with a relatively large footprint. It = is also a very new protocol, which really has only one domain of = application so far.

 

I have some doubts about Diameter, = mostly due to the fact that the IETF has still not finished standardizing it. I = would wait for Diameter to get usage in its main application domain, a Radius replacement, before extending it to other domains.

 

Question 2:

Of the remaining alternatives, = SNMPv3 makes the most sense: it is the most likely to be already required in = all platforms that will be engaged in MIDCOM.

 

Failing that, my preference would = be for a light weight XML based protocol.

 

-----Original Message-----
From: Louis-Nicolas Hamer [mailto:nhamer@nortelnetworks.com]
Sent: Tuesday, November = 05, 2002 9:37 AM
To: 'Melinda Shore'; midcom@ietf.org
Subject: RE: [midcom] = Straw poll

 

I think Diameter is not a good fit, I would remove it from the list of potential protocols.
It is way to bulky for = midcom.

I do think COPS, MEGACO & SNMP are very good fits.

cheers,
L-N

> -----Original Message-----
> From: Melinda Shore = [mailto:mshore@cisco.com] =
> Sent: Monday, = November 04, 2002 10:48 AM
> To: = midcom@ietf.org
> Subject: [midcom] = Straw poll
>
>
> I'm a little = concerned that we've only gotten ->1<- response
> to a straw poll = which seems to me to be central to the
> working group's interests.  If possible I'd like to get some
> more feedback on = the questions, and I'm also curious about
> the low response = level - are people busy with other stuff?
> Were the questions badly-phrased or inappropriate?  Etc. 
>
> I'd really like to = keep the working group moving forward.
> The question of = protocol selection is necessarily
> contentious and = political, and if there are process problems
> it would be a big = help to me if those could be pointed out
> so that they could = be addressed and fixed.
>
> = Thanks,
>
> = Melinda
> _______________________________________________
> midcom mailing = list
> = midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

=00 ------_=_NextPart_001_01C2875D.0439F8FA-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Nov 8 16:53:32 2002 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 QAA17488 for ; Fri, 8 Nov 2002 16:53:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8LtcS01620 for midcom-archive@odin.ietf.org; Fri, 8 Nov 2002 16:55: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 gA8Lphv01446; Fri, 8 Nov 2002 16:51:44 -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 gA8Lotv01306 for ; Fri, 8 Nov 2002 16:50:55 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17126 for ; Fri, 8 Nov 2002 16:48:18 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gA8Lofoj018375 for ; Fri, 8 Nov 2002 13:50:41 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAS75577; Fri, 8 Nov 2002 13:46:03 -0800 (PST) Message-Id: <200211082146.AAS75577@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Fri, 08 Nov 2002 16:50:45 -0500 Subject: [midcom] Winnowing down the list 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'd like to continue to try to narrow the list of midcom candidates. From the discussion so far it looks like a lot of people are dubious about COPS, so here's the question: Is there any objection to removing COPS from the list of candidate midcom protocols? If you object, please give a reason. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sat Nov 9 12:15:25 2002 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 MAA21769 for ; Sat, 9 Nov 2002 12:15:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA9HHT204129 for midcom-archive@odin.ietf.org; Sat, 9 Nov 2002 12:17: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 gA9HDhv03878; Sat, 9 Nov 2002 12:13: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 gA9H0Nv02674 for ; Sat, 9 Nov 2002 12:00:23 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21516 for ; Sat, 9 Nov 2002 11:57:49 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA9H0JIX023827 for ; Sat, 9 Nov 2002 09:00:19 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAS93386; Sat, 9 Nov 2002 08:55:36 -0800 (PST) Message-Id: <200211091655.AAS93386@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Sat, 09 Nov 2002 12:00:17 -0500 Subject: [midcom] For those that travel light 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 converted the three current working group drafts to handheld (Palm, etc.) DOC format and put them in a ZIP file. They're available for download at http://www.employees.org/~shore/midcomdocs.zip. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sat Nov 9 14:43:48 2002 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 OAA24722 for ; Sat, 9 Nov 2002 14:43:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA9Jjrg11727 for midcom-archive@odin.ietf.org; Sat, 9 Nov 2002 14:45: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 gA9JjGv11707; Sat, 9 Nov 2002 14:45: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 gA9JiKv11676 for ; Sat, 9 Nov 2002 14:44:20 -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 OAA24703 for ; Sat, 9 Nov 2002 14:41:43 -0500 (EST) Received: from jku07.fokus.fraunhofer.de (80-24-93-126.uc.nombres.ttd.es [80.24.93.126]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id gA9JhVn21280; Sat, 9 Nov 2002 20:43:32 +0100 Message-Id: <5.1.0.14.0.20021109202609.03de25c0@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 09 Nov 2002 20:27:12 +0100 To: "Christian Huitema" , "Louis-Nicolas Hamer" , "Melinda Shore" , From: Jiri Kuthan Subject: RE: [midcom] Straw poll In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 08:28 PM 11/8/2002, Christian Huitema wrote: >Failing that, my preference would be for a light weight XML based protocol. Thank you. I'm glad to hear ligth-weight. IMHO, simplicity buys us more than protocol recycling. -Jiri _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Nov 11 03:52:15 2002 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 DAA13676 for ; Mon, 11 Nov 2002 03:52:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAB8sSA29432 for midcom-archive@odin.ietf.org; Mon, 11 Nov 2002 03:54: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 gAB8rmv29413; Mon, 11 Nov 2002 03:53:50 -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 gAB8qCv29377 for ; Mon, 11 Nov 2002 03:52:12 -0500 Received: from mta1 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13639 for ; Mon, 11 Nov 2002 03:49:25 -0500 (EST) Received: from Rajithrcl1122 (mta1 [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTPA id <0H5E00LO5LV12G@mta1.huawei.com> for midcom@ietf.org; Mon, 11 Nov 2002 16:49:51 +0800 (CST) Date: Mon, 11 Nov 2002 14:22:27 +0530 From: Rajith To: Midcom Reply-to: rajithr@huawei.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [midcom] Qn. on draft-ietf-midcom-semantics-00 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 , When an NE behind NAT sends a packet to external, a session ( with a port bind ) will be established. I could not find any interface which would enable the agent query this session details. The interface I am looking at should give the agent details about the session or all existing sessions at NAT. The input parameter could be an internal ip (+ port) or wild carded. An interface which offers details about (an) already enabled session(s) without an associated policy ID is what I am looking for. Is this outside the scope of MIDCOM ? With Best Regards Rajith _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Nov 11 04:24:41 2002 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 EAA14099 for ; Mon, 11 Nov 2002 04:24:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAB9QsQ31267 for midcom-archive@odin.ietf.org; Mon, 11 Nov 2002 04: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 gAB9N7v31101; Mon, 11 Nov 2002 04:23: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 gAB9M6v31077 for ; Mon, 11 Nov 2002 04:22:06 -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 EAA14040 for ; Mon, 11 Nov 2002 04:19:22 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAB9LBY87462; Mon, 11 Nov 2002 10:21:47 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6824565F7C; Mon, 11 Nov 2002 10:20:03 +0100 (CET) Message-ID: <3DCF75E6.6060401@ccrle.nec.de> Date: Mon, 11 Nov 2002 10:18:30 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE MIME-Version: 1.0 To: rajithr@huawei.com Cc: Midcom Subject: Re: [midcom] Qn. on draft-ietf-midcom-semantics-00 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 Rajith, Rajith wrote: > Hi , > > When an NE behind NAT sends a packet to external, a session ( with a port > bind ) will be established. I could not find any interface which would > enable the agent query this session details. The interface I am looking at > should give the agent details about the session or all existing sessions at > NAT. The input parameter could be an internal ip (+ port) or wild carded. An > interface which offers details about (an) already enabled session(s) without > an associated policy ID is what I am looking for. When I got it right: You're looking for a protocol that fetches information about the current bindings in a NAT without configuring them earlier? Try the NAT MIB of the NAT working group: http://www.ietf.org/internet-drafts/draft-ietf-nat-natmib-05.txt Martin > > Is this outside the scope of MIDCOM ? > > > With Best Regards > > Rajith > > _______________________________________________ > 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 Mon Nov 11 10:19:44 2002 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 KAA21758 for ; Mon, 11 Nov 2002 10:19:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gABFLoq16291 for midcom-archive@odin.ietf.org; Mon, 11 Nov 2002 10:21:50 -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 gABFKsv16249; Mon, 11 Nov 2002 10:20: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 gABF6qv15055 for ; Mon, 11 Nov 2002 10: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 KAA21235 for ; Mon, 11 Nov 2002 10:04:15 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gABF6ZY09440; Mon, 11 Nov 2002 16:06:36 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 782B875DDD; Mon, 11 Nov 2002 16:05:46 +0100 (CET) Date: Mon, 11 Nov 2002 16:05:46 +0100 From: Juergen Quittek To: rajithr@huawei.com, Midcom Subject: Re: [midcom] Qn. on draft-ietf-midcom-semantics-00 Message-ID: <15663683.1037030746@[192.168.102.164]> In-Reply-To: References: 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 Rajith, We have not considered a function like this yet. I agree that it can be useful in certain situations. Currently, the semantics document tries to satisfy basic needs derived from the Midcom requirements document. It may be the case that the future Midcom protocol will support additional transactions. However, for convenience functions there is always a tradeoff between the number of transactions to be defined and implemented and the number of transactions to be performed for achieving a certain state or for getting certain information. With the current semantics, you can get the desired information by (1) using the group list transactions for learning about all groups you may access, then (2) for each group listing all memeber policy rules using the group status transactions, and finally (3) for each rule performing the policy rule status transactions that tells you whether a policy coveres the host you are interested in. Juergen -- Rajith wrote on 11 November 2002 14:22 +0530: > Hi , > > When an NE behind NAT sends a packet to external, a session ( with a port > bind ) will be established. I could not find any interface which would > enable the agent query this session details. The interface I am looking at > should give the agent details about the session or all existing sessions at > NAT. The input parameter could be an internal ip (+ port) or wild carded. An > interface which offers details about (an) already enabled session(s) without > an associated policy ID is what I am looking for. > > Is this outside the scope of MIDCOM ? > > > With Best Regards > > Rajith > > _______________________________________________ > 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 Mon Nov 11 11:37:37 2002 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 LAA24098 for ; Mon, 11 Nov 2002 11:37:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gABGdhZ21585 for midcom-archive@odin.ietf.org; Mon, 11 Nov 2002 11:39:43 -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 gABGcHv21502; Mon, 11 Nov 2002 11:38: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 gABGZFv20802 for ; Mon, 11 Nov 2002 11:35:15 -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 LAA23904 for ; Mon, 11 Nov 2002 11:32:38 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gABGYxx13476; Mon, 11 Nov 2002 11:35:00 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Nov 2002 11:35:00 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000400DF14@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Juergen Quittek'" , rajithr@huawei.com, Midcom Subject: RE: [midcom] Qn. on draft-ietf-midcom-semantics-00 Date: Mon, 11 Nov 2002 11:34:50 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) 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'll just add to this that I had this function in my original semantics document. I saw that it could be achieved the way Juergen describes it and accepted that the simplification was appropriate for a base-level semantic description. > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: Monday, November 11, 2002 4:06 PM > To: rajithr@huawei.com; Midcom > Subject: Re: [midcom] Qn. on draft-ietf-midcom-semantics-00 > > > Rajith, > > We have not considered a function like this yet. I agree that > it can be useful in certain situations. Currently, the > semantics document tries to satisfy basic needs derived from > the Midcom requirements document. > > It may be the case that the future Midcom protocol will > support additional transactions. However, for convenience > functions there is always a tradeoff between the number of > transactions to be defined and implemented and the number of > transactions to be performed for achieving a certain state or > for getting certain information. > > With the current semantics, you can get the desired > information by (1) using the group list transactions for > learning about all groups you may access, then (2) for each > group listing all memeber policy rules using the group status > transactions, and finally (3) for each rule performing the > policy rule status transactions that tells you whether a > policy coveres the host you are interested in. > > Juergen > > > -- Rajith wrote on 11 November 2002 14:22 +0530: > > > Hi , > > > > When an NE behind NAT sends a packet to external, a > session ( with a > > port bind ) will be established. I could not find any > interface which > > would enable the agent query this session details. The > interface I am > > looking at should give the agent details about the session or all > > existing sessions at NAT. The input parameter could be an > internal ip > > (+ port) or wild carded. An interface which offers details > about (an) > > already enabled session(s) without an associated policy ID > is what I > > am looking for. > > > > Is this outside the scope of MIDCOM ? > > > > > > With Best Regards > > > > Rajith > > > > _______________________________________________ > > 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 Mon Nov 11 12:02:23 2002 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 MAA24880 for ; Mon, 11 Nov 2002 12:02:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gABH4Tv22643 for midcom-archive@odin.ietf.org; Mon, 11 Nov 2002 12:04: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 gABH3Ev22458; Mon, 11 Nov 2002 12:03:14 -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 gABGwZv22254 for ; Mon, 11 Nov 2002 11:58:35 -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 LAA24637 for ; Mon, 11 Nov 2002 11:55:57 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gABGwLY18226; Mon, 11 Nov 2002 17:58:21 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 4896076692; Mon, 11 Nov 2002 17:57:31 +0100 (CET) Date: Mon, 11 Nov 2002 17:57:31 +0100 From: Juergen Quittek To: Tom-PT Taylor , rajithr@huawei.com, Midcom Subject: RE: [midcom] Qn. on draft-ietf-midcom-semantics-00 Message-ID: <22367983.1037037451@[192.168.102.164]> In-Reply-To: <4D79C746863DD51197690002A52CDA000400DF14@zcard0kc.ca.nortel.com> References: <4D79C746863DD51197690002A52CDA000400DF14@zcard0kc.ca.nortel.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 I think we should add this transaction to the list of semantics issues to be discussed in Atlanta. It is not a big issue to add this rather simple transaction to the current list of transactions and we can declare it as optional. However, it should be considered carefully, whether or not simplifying the the corresponding use-case is really worth the effort of extending the protocol definition and of all future protocol implementations. Juergen -- Tom-PT Taylor wrote on 11 November 2002 11:34 -0500: > I'll just add to this that I had this function in my original semantics > document. I saw that it could be achieved the way Juergen describes it and > accepted that the simplification was appropriate for a base-level semantic > description. > >> -----Original Message----- >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >> Sent: Monday, November 11, 2002 4:06 PM >> To: rajithr@huawei.com; Midcom >> Subject: Re: [midcom] Qn. on draft-ietf-midcom-semantics-00 >> >> >> Rajith, >> >> We have not considered a function like this yet. I agree that >> it can be useful in certain situations. Currently, the >> semantics document tries to satisfy basic needs derived from >> the Midcom requirements document. >> >> It may be the case that the future Midcom protocol will >> support additional transactions. However, for convenience >> functions there is always a tradeoff between the number of >> transactions to be defined and implemented and the number of >> transactions to be performed for achieving a certain state or >> for getting certain information. >> >> With the current semantics, you can get the desired >> information by (1) using the group list transactions for >> learning about all groups you may access, then (2) for each >> group listing all memeber policy rules using the group status >> transactions, and finally (3) for each rule performing the >> policy rule status transactions that tells you whether a >> policy coveres the host you are interested in. >> >> Juergen >> >> >> -- Rajith wrote on 11 November 2002 14:22 +0530: >> >> > Hi , >> > >> > When an NE behind NAT sends a packet to external, a >> session ( with a >> > port bind ) will be established. I could not find any >> interface which >> > would enable the agent query this session details. The >> interface I am >> > looking at should give the agent details about the session or all >> > existing sessions at NAT. The input parameter could be an >> internal ip >> > (+ port) or wild carded. An interface which offers details >> about (an) >> > already enabled session(s) without an associated policy ID >> is what I >> > am looking for. >> > >> > Is this outside the scope of MIDCOM ? >> > >> > >> > With Best Regards >> > >> > Rajith >> > >> > _______________________________________________ >> > 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 Mon Nov 11 14:29:52 2002 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 OAA28622 for ; Mon, 11 Nov 2002 14:29:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gABJVwh30591 for midcom-archive@odin.ietf.org; Mon, 11 Nov 2002 14:31:58 -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 gABJVOv30578; Mon, 11 Nov 2002 14:31:25 -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 gABJS3v30462 for ; Mon, 11 Nov 2002 14:28:03 -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 OAA28549 for ; Mon, 11 Nov 2002 14:25:25 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gABJRux28217 for ; Mon, 11 Nov 2002 14:27:56 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Nov 2002 14:27:56 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C043880D1@zcard031.ca.nortel.com> From: "Louis-Nicolas Hamer" To: midcom@ietf.org Subject: RE: [midcom] Winnowing down the list Date: Mon, 11 Nov 2002 14:27:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C289B8.6B649C7E" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C289B8.6B649C7E Content-Type: text/plain Melinda, all, Why do you say people are dubious about COPS? Unfortunately, it appears the persons who have spoken out against COPS don't intend to re-use any of the proposed protocols. So I think it is fair to say they are dubious to all the proposed protocols. The only reason invoked against COPS was the directionality requirement. Kwok explained in great lengths how this was not a big deal - it can be fixed quite easily. So I object to your proposal to remove COPS. As I have indicated before, I think COPS, SNMP and MEGACO are very good fits for MIDCOM. I would suggest that the best way forward would be to see what the WG decides on the approach to take to "pinpoint" the best protocol to use - I believe you have that point on the agenda for the Atlanta meeting, right? l-n > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Friday, November 08, 2002 4:51 PM > To: midcom@ietf.org > Subject: [midcom] Winnowing down the list > > > I'd like to continue to try to narrow the list of midcom > candidates. From the discussion so far it looks like a lot > of people are dubious about COPS, so here's the question: > > Is there any objection to removing COPS from the list of > candidate midcom protocols? If you object, please give a reason. > > Melinda > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C289B8.6B649C7E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [midcom] Winnowing down the list

Melinda, all,

Why do you say people are dubious about COPS?
Unfortunately, it appears the persons who have = spoken out against COPS don't intend to re-use any of the proposed = protocols. So I think it is fair to say they are dubious to all the = proposed protocols.

The only reason invoked against COPS was the = directionality requirement. Kwok explained in great lengths how this = was not a big deal - it can be fixed quite easily. So I object to your = proposal to remove COPS.

As I have indicated before, I think COPS, SNMP and = MEGACO are very good fits for MIDCOM.
I would suggest that the best way forward would be = to see what the WG decides on the approach to take to
"pinpoint" the best protocol to use - I = believe you have
that point on the agenda for the Atlanta meeting, = right?

l-n


> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Friday, November 08, 2002 4:51 PM
> To: midcom@ietf.org
> Subject: [midcom] Winnowing down the = list
>
>
> I'd like to continue to try to narrow the list = of midcom
> candidates.  From the discussion so far it = looks like a lot
> of people are dubious about COPS, so here's the = question:
>
> Is there any objection to removing COPS from = the list of
> candidate midcom protocols?  If you = object, please give a reason.
>
> Melinda
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C289B8.6B649C7E-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Nov 11 14:46:28 2002 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 OAA29050 for ; Mon, 11 Nov 2002 14:46:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gABJmZn31680 for midcom-archive@odin.ietf.org; Mon, 11 Nov 2002 14:48:35 -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 gABJmCv31665; Mon, 11 Nov 2002 14:48: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 gABJjmv31614 for ; Mon, 11 Nov 2002 14:45:48 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28995 for ; Mon, 11 Nov 2002 14:43:11 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gABJjgIX021638; Mon, 11 Nov 2002 11:45:42 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAT29102; Mon, 11 Nov 2002 11:41:00 -0800 (PST) Message-Id: <200211111941.AAT29102@mira-sjc5-4.cisco.com> To: "Louis-Nicolas Hamer" cc: midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Winnowing down the list In-Reply-To: Message from "Louis-Nicolas Hamer" of "Mon, 11 Nov 2002 14:27:48 EST." <9FBD322B7824D511B36900508BF93C9C043880D1@zcard031.ca.nortel.com> Date: Mon, 11 Nov 2002 14:45:40 -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: , > Why do you say people are dubious about COPS? > Unfortunately, it appears the persons who have spoken out > against COPS don't intend to re-use any of the proposed > protocols. So I think it is fair to say they are dubious > to all the proposed protocols. The reason that the question about COPS was posed is that there has been more anti-COPS sentiment expressed than anti-anything else. > The only reason invoked against COPS was the directionality requirement. > Kwok explained in great lengths how this was not a big deal - it can be > fixed quite easily. So I object to your proposal to remove COPS. Fair enough, although I will mention that I thought Kwok's proposed workaround to be quite awkward. > I would suggest that the best way forward would be to see > what the WG decides on the approach to take to "pinpoint" > the best protocol to use - I believe you have that point > on the agenda for the Atlanta meeting, right? Briefly. Note that the IETF does its work on mailing lists and that meetings are for discussions that would benefit from face-to-face interactions. Any decisions to be made will be made here, on the mailing list. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Nov 11 18:45:51 2002 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 SAA06229 for ; Mon, 11 Nov 2002 18:45:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gABNlx313322 for midcom-archive@odin.ietf.org; Mon, 11 Nov 2002 18:47:59 -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 gABNiKv13252; Mon, 11 Nov 2002 18:44:20 -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 gABNh9v13225 for ; Mon, 11 Nov 2002 18:43:09 -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 SAA06130 for ; Mon, 11 Nov 2002 18:40:30 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gABNh1Y25881 for ; Tue, 12 Nov 2002 00:43:01 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] (unknown [192.168.102.31]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B396C7676C for ; Tue, 12 Nov 2002 00:42:10 +0100 (CET) Date: Tue, 12 Nov 2002 00:42:09 +0100 From: Juergen Quittek To: midcom@ietf.org Message-ID: <11900552.1037061729@[192.168.102.31]> 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 Subject: [midcom] Midcom terminology clarification 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 When refining the protocol evaluation document, Mary Barnes pointed to a sentence in the midcom framework that I apparently had not read carefully enough until today. In section "2 Terminology" the framework document explains first the terms "proxy" and "ALG". It makes clear that ALGs are different from proxies. Then, when explaining the term "midcom agent", it says: "MIDCOM agents are entities performing ALG functions". Is there consensus on the Midcom list that this statement is not exclusive? I don't see any reason for excluding non-ALGs (proxies, end-hosts, ...) from acting as MIDCOM agents. Juergen _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 12 05:06:21 2002 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 FAA26353 for ; Tue, 12 Nov 2002 05:06:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACA8P421681 for midcom-archive@odin.ietf.org; Tue, 12 Nov 2002 05:08: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 gACA4Xv21001; Tue, 12 Nov 2002 05:04: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 gACA3iv20962 for ; Tue, 12 Nov 2002 05:03: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 FAA26274 for ; Tue, 12 Nov 2002 05:01:09 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gACA3gY46404; Tue, 12 Nov 2002 11:03:42 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 33C4214C2A; Tue, 12 Nov 2002 11:02:50 +0100 (CET) Message-ID: <3DD0D1BE.7000704@ccrle.nec.de> Date: Tue, 12 Nov 2002 11:02:38 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE MIME-Version: 1.0 To: Louis-Nicolas Hamer Cc: midcom@ietf.org Subject: Re: [midcom] Winnowing down the list References: <9FBD322B7824D511B36900508BF93C9C043880D1@zcard031.ca.nortel.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 Louis-Nicolas Hamer wrote: > Melinda, all, > [....] > > The only reason invoked against COPS was the directionality requirement. > Kwok explained in great lengths how this was not a big deal - it can be > fixed quite easily. So I object to your proposal to remove COPS. Hmm, there is another reason against COPS: The COPS PEP is not able to receive configuration data from multiple PDP for the *same* resource, e.g. the middlebox can not receive policy rule configuration requests from different agents for the same packet filter at the same time. Martin > > As I have indicated before, I think COPS, SNMP and MEGACO are very good > fits for MIDCOM. > I would suggest that the best way forward would be to see what the WG > decides on the approach to take to > "pinpoint" the best protocol to use - I believe you have > that point on the agenda for the Atlanta meeting, right? > > l-n > > > > -----Original Message----- > > From: Melinda Shore [mailto:mshore@cisco.com] > > Sent: Friday, November 08, 2002 4:51 PM > > To: midcom@ietf.org > > Subject: [midcom] Winnowing down the list > > > > > > I'd like to continue to try to narrow the list of midcom > > candidates. From the discussion so far it looks like a lot > > of people are dubious about COPS, so here's the question: > > > > Is there any objection to removing COPS from the list of > > candidate midcom protocols? If you object, please give a reason. > > > > 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 Nov 12 05:21:38 2002 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 FAA26527 for ; Tue, 12 Nov 2002 05:21:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACANf222059 for midcom-archive@odin.ietf.org; Tue, 12 Nov 2002 05:23: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 gACAK7v21990; Tue, 12 Nov 2002 05:20: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 gACAJ3v21926 for ; Tue, 12 Nov 2002 05:19:03 -0500 Received: from zctfs063.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26442 for ; Tue, 12 Nov 2002 05:16:27 -0500 (EST) Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gACAIZa20855; Tue, 12 Nov 2002 11:18:35 +0100 (MET) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Nov 2002 11:18:34 +0100 Message-ID: From: "Cedric Aoun" To: "'Martin Stiemerling'" , "Louis-Nicolas Hamer" Cc: midcom@ietf.org Subject: RE: [midcom] Winnowing down the list Date: Tue, 12 Nov 2002 11:18:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28A34.DA5E2772" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C28A34.DA5E2772 Content-Type: text/plain; charset="iso-8859-1" Martin, I believe that it is clearly stated in the protocol evaluation document that several PDPs can access to the same resource by using an underlying resource management function assisted with local policies. I think we have closed on this one before the previous IETF meeting. Cedric -----Original Message----- From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] Sent: 12 November 2002 11:03 To: Hamer, Louis-Nicolas [CAR:AN22:EXCH] Cc: midcom@ietf.org Subject: Re: [midcom] Winnowing down the list Louis-Nicolas Hamer wrote: > Melinda, all, > [....] > > The only reason invoked against COPS was the directionality requirement. > Kwok explained in great lengths how this was not a big deal - it can be > fixed quite easily. So I object to your proposal to remove COPS. Hmm, there is another reason against COPS: The COPS PEP is not able to receive configuration data from multiple PDP for the *same* resource, e.g. the middlebox can not receive policy rule configuration requests from different agents for the same packet filter at the same time. Martin > > As I have indicated before, I think COPS, SNMP and MEGACO are very good > fits for MIDCOM. > I would suggest that the best way forward would be to see what the WG > decides on the approach to take to > "pinpoint" the best protocol to use - I believe you have > that point on the agenda for the Atlanta meeting, right? > > l-n > > > > -----Original Message----- > > From: Melinda Shore [mailto:mshore@cisco.com] > > Sent: Friday, November 08, 2002 4:51 PM > > To: midcom@ietf.org > > Subject: [midcom] Winnowing down the list > > > > > > I'd like to continue to try to narrow the list of midcom > > candidates. From the discussion so far it looks like a lot > > of people are dubious about COPS, so here's the question: > > > > Is there any objection to removing COPS from the list of > > candidate midcom protocols? If you object, please give a reason. > > > > 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 ------_=_NextPart_001_01C28A34.DA5E2772 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Winnowing down the list

Martin,
I believe that it is clearly stated in the protocol = evaluation document that
several PDPs can access to the same resource by = using an underlying resource
management function assisted with local policies. I = think we have closed on this
one before the previous IETF meeting.
Cedric


-----Original Message-----
From: Martin Stiemerling [mailto:Martin.Stiemerlin= g@ccrle.nec.de]
Sent: 12 November 2002 11:03
To: Hamer, Louis-Nicolas [CAR:AN22:EXCH]
Cc: midcom@ietf.org
Subject: Re: [midcom] Winnowing down the list



Louis-Nicolas Hamer wrote:

> Melinda, all,
>
[....]


>
> The only reason invoked against COPS was the = directionality requirement.
> Kwok explained in great lengths how this was = not a big deal - it can be
> fixed quite easily. So I object to your = proposal to remove COPS.


Hmm, there is another reason against COPS:
The COPS PEP is not able to receive configuration = data from multiple PDP
for the *same* resource, e.g. the middlebox can not = receive policy rule
configuration requests from different agents for the = same packet filter
at the same time.

Martin


>
> As I have indicated before, I think COPS, SNMP = and MEGACO are very good
> fits for MIDCOM.
> I would suggest that the best way forward would = be to see what the WG
> decides on the approach to take to
> "pinpoint" the best protocol to use - = I believe you have
> that point on the agenda for the Atlanta = meeting, right?
>
> l-n
>
>
>  > -----Original Message-----
>  > From: Melinda Shore [mailto:mshore@cisco.com]
>  > Sent: Friday, November 08, 2002 4:51 = PM
>  > To: midcom@ietf.org
>  > Subject: [midcom] Winnowing down the = list
>  >
>  >
>  > I'd like to continue to try to = narrow the list of midcom
>  > candidates.  From the = discussion so far it looks like a lot
>  > of people are dubious about COPS, so = here's the question:
>  >
>  > Is there any objection to removing = COPS from the list of
>  > candidate midcom protocols?  If = you object, please give a reason.
>  >
>  > 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

------_=_NextPart_001_01C28A34.DA5E2772-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 12 05:28:29 2002 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 FAA26583 for ; Tue, 12 Nov 2002 05:28:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACAUWR22235 for midcom-archive@odin.ietf.org; Tue, 12 Nov 2002 05:30:32 -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 gACAR5v22148; Tue, 12 Nov 2002 05:27: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 gACAQwv22133 for ; Tue, 12 Nov 2002 05:26:58 -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 FAA26551 for ; Tue, 12 Nov 2002 05:24:22 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gACAQuY48459; Tue, 12 Nov 2002 11:26:56 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 1C3E666B4D; Tue, 12 Nov 2002 11:26:04 +0100 (CET) Message-ID: <3DD0D6FB.6010505@ccrle.nec.de> Date: Tue, 12 Nov 2002 11:24:59 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE MIME-Version: 1.0 To: Cedric Aoun Cc: Louis-Nicolas Hamer , midcom@ietf.org Subject: Re: [midcom] Winnowing down the list 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 Cedric Aoun wrote: > Martin, > I believe that it is clearly stated in the protocol evaluation document > that > several PDPs can access to the same resource by using an underlying > resource > management function assisted with local policies. I think we have closed > on this > one before the previous IETF meeting. ...with the words (see meeting minutes): There is a glaring mismatch between MIDCOM framework and COPS model. Martin > Cedric > > > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: 12 November 2002 11:03 > To: Hamer, Louis-Nicolas [CAR:AN22:EXCH] > Cc: midcom@ietf.org > Subject: Re: [midcom] Winnowing down the list > > > > Louis-Nicolas Hamer wrote: > > > Melinda, all, > > > [....] > > > > > > The only reason invoked against COPS was the directionality requirement. > > Kwok explained in great lengths how this was not a big deal - it can be > > fixed quite easily. So I object to your proposal to remove COPS. > > > Hmm, there is another reason against COPS: > The COPS PEP is not able to receive configuration data from multiple PDP > for the *same* resource, e.g. the middlebox can not receive policy rule > configuration requests from different agents for the same packet filter > at the same time. > > Martin > > > > > > As I have indicated before, I think COPS, SNMP and MEGACO are very good > > fits for MIDCOM. > > I would suggest that the best way forward would be to see what the WG > > decides on the approach to take to > > "pinpoint" the best protocol to use - I believe you have > > that point on the agenda for the Atlanta meeting, right? > > > > l-n > > > > > > > -----Original Message----- > > > From: Melinda Shore [mailto:mshore@cisco.com] > > > Sent: Friday, November 08, 2002 4:51 PM > > > To: midcom@ietf.org > > > Subject: [midcom] Winnowing down the list > > > > > > > > > I'd like to continue to try to narrow the list of midcom > > > candidates. From the discussion so far it looks like a lot > > > of people are dubious about COPS, so here's the question: > > > > > > Is there any objection to removing COPS from the list of > > > candidate midcom protocols? If you object, please give a reason. > > > > > > 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 Tue Nov 12 09:14:58 2002 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 JAA00923 for ; Tue, 12 Nov 2002 09:14:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACEH3V02482 for midcom-archive@odin.ietf.org; Tue, 12 Nov 2002 09:17:03 -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 gACEDQv02362; Tue, 12 Nov 2002 09:13: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 gACECcv02318 for ; Tue, 12 Nov 2002 09:12:38 -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 JAA00726 for ; Tue, 12 Nov 2002 09:10:01 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gACECXY65700; Tue, 12 Nov 2002 15:12:33 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 9C35276B7A; Tue, 12 Nov 2002 15:11:40 +0100 (CET) Date: Tue, 12 Nov 2002 15:11:40 +0100 From: Juergen Quittek To: Cedric Aoun , "'Martin Stiemerling'" , Louis-Nicolas Hamer Cc: midcom@ietf.org Subject: RE: [midcom] Winnowing down the list Message-ID: <15225172.1037113900@[192.168.102.164]> In-Reply-To: References: 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 Cedric, -- Cedric Aoun wrote on 12 November 2002 11:18 +0100: > Martin, > I believe that it is clearly stated in the protocol evaluation document that > several PDPs can access to the same resource by using an underlying resource > management function assisted with local policies. I think we have closed on > this > one before the previous IETF meeting. I agree, we have closed this issue as far as the text in the evaluation document is concerend. All protocols have several advantages and some problems. However, the evaluation document does neither weight the problems, nor does it give a recommendation concerning protocol selection. Therefore, we now have to enter the next stage. We have to weight the advantages and disadvantages of the protocols in order to get closer to a recommendation ot better: a protocol selection. And as far as I understand Martin, he is not aiming at changing any line in the evaluation, but at getting closer to a recommendation. One step in this direction is looking again at the disadvantages of the candidate protocols, which are described in the evaluation document. And then we have to find out for each of them, whether it is just a minor disadvantage or a serious problem. In the case you are discussing with Martin, I see at first glance technical problem that can be solved, but I am not happy with using COPS-PR while violating its specification in RFC 3084. RFC 3084 says: "There may be one or more PIBs for given area of policy and different areas of policy may have different sets of PIBs." (Section 1) So let's assume we have a Midcom PIB in the Midcom area. "Second, as it [COPS] has a single connection between the policy client and server per area of policy control identified by a COPS Client-Type, it guarantees only one server updates a particular policy configuration at any given time. Such a policy configuration is effectively locked, even from local console configuration, while the PEP is connected to a PDP via COPS." (Section 1.1) Conclusion: only a single Midcom agent would be allowed to request or release middlebox resources. I know that technically we could just ignore this and it works, but I do not feel comfortable when doing so. Support for doing so is given by "In order to support a model that includes multiple PDPs controlling non-overlapping areas of policy on a single PEP, the client-type specified by the PEP to the PDP is unique for the area of policy being managed. A single client-type for a given area of policy (e.g., QoS) will be used for all PIBs that exist in that area. The client should treat all the COPS-PR client-types it supports as non-overlapping and independent namespaces where instances MUST NOT be shared." (Section 1) So maybe we can map agent identfiers to client types and use a lot of existing COPS functonality. But still it leaves the impression of a hack rather than of a solution. Juergen > Cedric > > > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: 12 November 2002 11:03 > To: Hamer, Louis-Nicolas [CAR:AN22:EXCH] > Cc: midcom@ietf.org > Subject: Re: [midcom] Winnowing down the list > > > > Louis-Nicolas Hamer wrote: > >> Melinda, all, >> > [....] > > >> >> The only reason invoked against COPS was the directionality requirement. >> Kwok explained in great lengths how this was not a big deal - it can be >> fixed quite easily. So I object to your proposal to remove COPS. > > > Hmm, there is another reason against COPS: > The COPS PEP is not able to receive configuration data from multiple PDP > for the *same* resource, e.g. the middlebox can not receive policy rule > configuration requests from different agents for the same packet filter > at the same time. > > Martin > > >> >> As I have indicated before, I think COPS, SNMP and MEGACO are very good >> fits for MIDCOM. >> I would suggest that the best way forward would be to see what the WG >> decides on the approach to take to >> "pinpoint" the best protocol to use - I believe you have >> that point on the agenda for the Atlanta meeting, right? >> >> l-n >> >> >> > -----Original Message----- >> > From: Melinda Shore [mailto:mshore@cisco.com] >> > Sent: Friday, November 08, 2002 4:51 PM >> > To: midcom@ietf.org >> > Subject: [midcom] Winnowing down the list >> > >> > >> > I'd like to continue to try to narrow the list of midcom >> > candidates. From the discussion so far it looks like a lot >> > of people are dubious about COPS, so here's the question: >> > >> > Is there any objection to removing COPS from the list of >> > candidate midcom protocols? If you object, please give a reason. >> > >> > 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 Tue Nov 12 14:48:51 2002 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 OAA11775 for ; Tue, 12 Nov 2002 14:48:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACJowJ24989 for midcom-archive@odin.ietf.org; Tue, 12 Nov 2002 14:50:58 -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 gACJlEv24817; Tue, 12 Nov 2002 14:47:14 -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 gACJkhv24776 for ; Tue, 12 Nov 2002 14:46:43 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11690 for ; Tue, 12 Nov 2002 14:44:04 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gACJkVep028093 for ; Tue, 12 Nov 2002 11:46:31 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAT70215; Tue, 12 Nov 2002 11:41:53 -0800 (PST) Message-Id: <200211121941.AAT70215@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Tue, 12 Nov 2002 14:46:30 -0500 Subject: [midcom] Protocol selection process 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: , Ever optimistic, I'd like to try for getting a protcol selected by the end of December. We've already eliminated one candidate, and I'd like to eliminate at least one more, preferably two, before moving directly into selection. The evaluation document does an excellent job of comparing the protocols against the requirements and framework, but there may be intangibles (or nearly tangibles) to be considered as well, such as whether or not the protocol has been deployed and whether or not it's been deployed in the types of devices we anticipate being of interest to midcom. We also need to identify showstoppers - things that might make a given protocol impossible to deploy. So, the job at hand is to eliminate another protocol from consideration. It may be the case that we ultimately find that none of these protocols is suitable, but the default position is that at least one of them is - the onus would be on us to demonstrate definitively otherwise. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 12 15:47:33 2002 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 PAA14758 for ; Tue, 12 Nov 2002 15:47:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACKngX29228 for midcom-archive@odin.ietf.org; Tue, 12 Nov 2002 15:49:42 -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 gACKn7v29178; Tue, 12 Nov 2002 15: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 gACKmev29134 for ; Tue, 12 Nov 2002 15:48:40 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14642 for ; Tue, 12 Nov 2002 15:46:01 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gACKmYNi028750 for ; Tue, 12 Nov 2002 12:48:34 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAT73171; Tue, 12 Nov 2002 12:43:53 -0800 (PST) Message-Id: <200211122043.AAT73171@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Tue, 12 Nov 2002 15:48:32 -0500 Subject: [midcom] IETF draft tracker 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: , For those who aren't on the main ietf mailing lists and who may not have seen the announcement, the IESG is making a draft tracking tool available for public use. It allows you to find and follow the status of working group drafts as they wend their way through the review and publication process. The URL is: https://datatracker.ietf.org/public/pidtracker.cgi Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 12 16:20:24 2002 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 QAA16233 for ; Tue, 12 Nov 2002 16:20:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACLMWc31545 for midcom-archive@odin.ietf.org; Tue, 12 Nov 2002 16:22:32 -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 gACLM9v31473; Tue, 12 Nov 2002 16:22: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 gACLL4v31299 for ; Tue, 12 Nov 2002 16:21:04 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16144 for ; Tue, 12 Nov 2002 16:18:25 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gACLLAB16383 for ; Tue, 12 Nov 2002 15:21:10 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Nov 2002 15:20:57 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CABC@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom@ietf.org'" Date: Tue, 12 Nov 2002 15:20:51 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] Updated Protocol evaluation document available Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi all, We (David H., Juergen and myself) have completed the task of updating the SNMP section per the feedback from the IESG. Thanks to David Harrington for providing his expertise in this area. The following summarizes the changes: - Section 1.1 has been expanded to provide more detail on the architectural aspects of SNMP and its applicability as the MIDCOM protocol. - For Section 2, the Item level compliancies, which had been quite general statements, now contain quite a bit more detail on the aspects of SNMP which satisfy the requirement. - In the conclusion, the "counts" were updated as the updated evaluation resulted in 2.2.3, 2.2.5 and 2.2.6 being changed from P+ to T. - The conclusion text for SNMP was also updated. - References for SNMP were updated To facilitate the task of re-reviewing the document, I have put a Microsoft word version of the document which has the changes marked on my server at: http://home.attbi.com/~mbarnes42/IETF/draft-ietf-midcom-protocol-eval-06-v0- 3-w-chgs.doc The word version, with the changes incorporated, which also contains minor editorial changes necessary to generate the appropriate text format of the document (and some other editorial nits) is also on the server: http://home.attbi.com/~mbarnes42/IETF/draft-ietf-midcom-protocol-eval-06-v0- 3.doc The text version, which will be submitted to the repository the week of the IETF-55 meeting, is also on the server: http://home.attbi.com/~mbarnes42/IETF/draft-ietf-midcom-protocol-eval-06.txt Note, that I did a few other edits not related to SNMP while I was updating the document: - Updated the conclusion text for RSIP to reflect WG concensus wrt applicability as the MIDCOM protocol - Updated the MIDCOM references to include the RFC #s. - Updated the Diameter protocol reference. So, along with considering what's the next protocol to be eliminated, please do take time to review the updated document and provide feedback on the list. We will need to go through WGLC again and it would be nice to have the document ready right after the IETF-55 meeting. Regards, Mary H. Barnes mbarnes@nortelnetworks.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 12 16:33:46 2002 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 QAA16996 for ; Tue, 12 Nov 2002 16:33:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACLZth32291 for midcom-archive@odin.ietf.org; Tue, 12 Nov 2002 16:35:55 -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 gACLW7v32031; Tue, 12 Nov 2002 16:32: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 gACLRiv31818 for ; Tue, 12 Nov 2002 16:27:44 -0500 Received: from relay.cosmoweb.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16584 for ; Tue, 12 Nov 2002 16:25:04 -0500 (EST) Received: from FUNKYMONKEY (73-227-234-66.cosmoweb.net [66.234.227.73]) by relay.cosmoweb.net (8.11.6/8.11.6) with ESMTP id gACL94516274 for ; Tue, 12 Nov 2002 16:09:04 -0500 Date: Tue, 12 Nov 2002 16:31:01 -0500 From: Cyrus Shaoul To: midcom@ietf.org Message-Id: <20021112160226.CD5C.CYRUS@ntt-at.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.07 Content-Transfer-Encoding: 7bit Subject: [midcom] Re: First draft of agenda for IETF 55 (Melinda Shore) 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 Dear Melinda, I am newcomer to the midcom world, and I am planning to attend the meeting in Atlanta. I had a question for you: In your agenda, you mentioned in the last line that there would be 15 minutes devoted to "Midcom protocol selection/process" Does this mean "the selection process will be discussed", or "the selection process will take place"? Thanks in advance, Cyrus Cyrus Shaoul NTT Advanced Technology Corp. cyrus@ntt-at.com http://www.ntt-at.com/ _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 12 17:47:36 2002 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 RAA18833 for ; Tue, 12 Nov 2002 17:47:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACMnkF04955 for midcom-archive@odin.ietf.org; Tue, 12 Nov 2002 17:49: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 gACMnKv04941; Tue, 12 Nov 2002 17:49:20 -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 gACMmlv04901 for ; Tue, 12 Nov 2002 17:48:47 -0500 Received: from relay.cosmoweb.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18810 for ; Tue, 12 Nov 2002 17:46:06 -0500 (EST) Received: from FUNKYMONKEY (73-227-234-66.cosmoweb.net [66.234.227.73]) by relay.cosmoweb.net (8.11.6/8.11.6) with ESMTP id gACMU6518030 for ; Tue, 12 Nov 2002 17:30:06 -0500 Date: Tue, 12 Nov 2002 17:52:04 -0500 From: Cyrus Shaoul To: midcom@ietf.org Message-Id: <20021112175154.CD67.CYRUS@ntt-at.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.07 Content-Transfer-Encoding: 7bit Subject: [midcom] Re: First draft of agenda for IETF 55 (Melinda Shore) 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 Dear Melinda, I am newcomer to the midcom world, and I am planning to attend the meeting in Atlanta. I had a question for you: In your agenda, you mentioned in the last line that there would be 15 minutes devoted to "Midcom protocol selection/process" Does this mean "the selection process will be discussed", or "the selection process will take place"? Thanks in advance, Cyrus Cyrus Shaoul NTT Advanced Technology Corp. cyrus@ntt-at.com http://www.ntt-at.com/ _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 12 18:01:27 2002 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 SAA19278 for ; Tue, 12 Nov 2002 18:01:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACN3bY05486 for midcom-archive@odin.ietf.org; Tue, 12 Nov 2002 18:03:37 -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 gACN39v05472; Tue, 12 Nov 2002 18:03: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 gACN2Fv05458 for ; Tue, 12 Nov 2002 18:02:15 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19253 for ; Tue, 12 Nov 2002 17:59:34 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gACN28Ni009383; Tue, 12 Nov 2002 15:02:08 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAT79645; Tue, 12 Nov 2002 14:57:27 -0800 (PST) Message-Id: <200211122257.AAT79645@mira-sjc5-4.cisco.com> To: Cyrus Shaoul cc: midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Re: First draft of agenda for IETF 55 (Melinda Shore) In-Reply-To: Message from Cyrus Shaoul of "Tue, 12 Nov 2002 17:52:04 EST." <20021112175154.CD67.CYRUS@ntt-at.com> Date: Tue, 12 Nov 2002 18:02:06 -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: , > Does this mean "the selection process will be discussed", or "the > selection process will take place"? We'll be talking about the selection process. The selection process itself will be executed on the mailing list. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Nov 13 04:32:42 2002 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 EAA25964 for ; Wed, 13 Nov 2002 04:32:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAD9YvU15917 for midcom-archive@odin.ietf.org; Wed, 13 Nov 2002 04:34:57 -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 gAD9Y6v15903; Wed, 13 Nov 2002 04: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 gAD9Wsv15848 for ; Wed, 13 Nov 2002 04:32:54 -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 EAA25930 for ; Wed, 13 Nov 2002 04:30:08 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAD9WgY02253 for ; Wed, 13 Nov 2002 10:32:42 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 4810961563 for ; Wed, 13 Nov 2002 10:31:47 +0100 (CET) Message-ID: <3DD21C04.90205@ccrle.nec.de> Date: Wed, 13 Nov 2002 10:31:48 +0100 From: Martin Stiemerling Organization: NEC -- Network Labs Europe 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] 55th IETF meeting: Topics about Semantics Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Tom, Juergen and I have compiled a list of topics regarding the MIDCOM semantics and we will do a 20 minutes presentation about these issues at the Atlanta meeting. Please find these topics in the list below: - Why PRR in general? - Action to be taken on PRR: Only one-side reservation at NAT (independent wether traditional or twice NAT) or two-side reservation. - PER address return values: return always A1/A2 addresses (that may equal to A0/A3) or return an "EMPTY"/"NONE" identifier - Divide PER for state transition PID_UNUSED->PID_USED and PID_RESERVED->PID_USED into two different PERs - Wildcarding of IP addresses and port numbers - Proposed changes in group transaction: Remove group lifetime and thus remove GE and AGD transactions/notifications. Keep GS, GL, GLC. - Queuing model for incoming messages: Add "first come - first served" statement to section 2.1.2 "atomicity"? See you in Atlanta 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 Thu Nov 14 08:34:07 2002 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 IAA18463 for ; Thu, 14 Nov 2002 08:34:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEDaBX28852 for midcom-archive@odin.ietf.org; Thu, 14 Nov 2002 08:36:11 -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 gAEDZbv28750; Thu, 14 Nov 2002 08:35: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 gAEDWNv28619 for ; Thu, 14 Nov 2002 08:32:23 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18351 for ; Thu, 14 Nov 2002 08:29:45 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gAEDWAsA009304 for ; Thu, 14 Nov 2002 05:32:10 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAU41918; Thu, 14 Nov 2002 05:27:41 -0800 (PST) Message-Id: <200211141327.AAU41918@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Thu, 14 Nov 2002 08:32:19 -0500 Subject: [midcom] STUN issues 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 STUN document (http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-03.txt) has come back from IESG review with comments that need to be addressed. Thanks to the excellent new document tracker you can take a look at the comments yourself - find the document and click on the "DETAIL" button. The comments are listed in the "Comment log" and you can look at the individual comments, or you can look at the ballot and discussion summary by clicking the "Available" link in the "Detail Info" box at the top of the page (I had to ask for help finding that one, myself). Note that the summary does *not* include the most recent entry in the comment log. Specific issues include 1) miscellaneous wordsmithing - places where the text is unclear 2) a request to restructure return codes and rethink some of the error handling 3) improve our use of the FLAGS attribute 4) more explicit mention of the desirability of having STUN servers topologically "near" the endpoint with which we're communicating 5) modification of use of the RESPONSE-ADDRESS to protect against reflector attacks 6) a suggestion from one of the security ADs to forgo the use of client certs, along with a proposal for stateless authentication 7) a suggestion that this is one case where we don't want v6 compatibility and that the use of AAAA records should be removed Most of this can be handled through editing, but as a group we do need to: 1) accept or reject the authentication proposal 2) fix the FLAGS attribute 3) deal with the return codes issue 4) deal with the RESPONSE-ADDRESS issue We will be discussing this in Atlanta, but as always, the substance of our work happens here, on the mailing list. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Nov 14 11:13:43 2002 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 LAA22812 for ; Thu, 14 Nov 2002 11:13:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEGFou06231 for midcom-archive@odin.ietf.org; Thu, 14 Nov 2002 11:15:50 -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 gAEGFJv06201; Thu, 14 Nov 2002 11:15:19 -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 gAEG8Av06025 for ; Thu, 14 Nov 2002 11:08:10 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22592 for ; Thu, 14 Nov 2002 11:05:31 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gAEG7ssA003242 for ; Thu, 14 Nov 2002 08:07:54 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAU45166; Thu, 14 Nov 2002 08:03:25 -0800 (PST) Message-Id: <200211141603.AAU45166@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Thu, 14 Nov 2002 11:08:03 -0500 Subject: [midcom] text conferencing at the 55th IETF meeting in Atlanta 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: , As I've mentioned in other email, there's a text conferencing experiment taking place at next week's IETF meeting. We don't seem to have enough interest to justify asking for a volunteer scribe for this, but it may be worthwhile to try doing this in a more ad-hoc fashion. Interested individuals, both in attendance at the meeting and who aren't able to attend, can connect to the server during the meeting (note that the transcript is being recorded and retained for posteriority). It's a jabber server and there are clients available for most platforms. For Unix users, I've found that Psi works pretty well. I've appended conferencing instructions below. Melinda ------- Forwarded Message At each IETF meeting, two of the working group meeting rooms are equipped for video multicast and remote participation. That is, for every IETF meeting slot, two of the working groups can see and hear the meeting. For the 55th IETF, in *addition* to the usual network A/V, text conferencing will be provided for every working group that meets. All of the conference rooms will be hosted on conference.ietf.jabber.com and each is named using the official IETF abbreviation found in the agenda (e.g., "apparea", "dhc", "forces", and so on -- for all the examples that follow, we'll use "foobar" as the abbreviation). Each conference room also has a 'bot which records everything that gets sent. So, the minute taker can review this information right after the meeting. 1. Before the meeting: 1.1. If you want to participate If you don't already have one, get yourself a Jabber client, here are some suggestions: platform suggestion -------- ---------- win32 http://exodus.jabberstudio.org 'nix http://gabber.sf.net macos http://jabberfox.sf.net When you start the client for the first time, it will eventually ask if you want to register on a public server. Go ahead and do that. If you want to find out more, instead of choosing these defaults, here are pointers to some additional information: list of clients: http://www.jabber.org/user/clientlist.php howto: http://www.jabber.org/user/userguide/ server list: http://www.jabber.org/user/publicservers.php To make sure everything is running ok, do a "Join Group Chat" with your Jabber client: Group/Room: testing Server: conference.ietf.jabber.com This conference room is up and running right now (although probably no one will be in it when you connect). [ ... ] 2.4. Where to find the conference log http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/foobar/ 2.5. Finally This is an experiment. Let's see how well it works and discuss it after the meeting. ####### - --Multipart_Thu__7_Nov_2002_15:21:56_-0800_08914000-- ------- End of Forwarded Message _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Nov 14 15:28:40 2002 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 PAA29768 for ; Thu, 14 Nov 2002 15:28:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEKUnA22547 for midcom-archive@odin.ietf.org; Thu, 14 Nov 2002 15:30: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 gAEKUMv22525; Thu, 14 Nov 2002 15:30: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 gAEKRJv22401 for ; Thu, 14 Nov 2002 15:27:19 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29554 for ; Thu, 14 Nov 2002 15:24:39 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAEKRPl21377 for ; Thu, 14 Nov 2002 14:27:25 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Nov 2002 14:27:12 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CACF@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom@ietf.org'" Subject: RE: [midcom] Updated Protocol evaluation document available Date: Thu, 14 Nov 2002 14:27:11 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi folks, Just a reminder that although it's not in the repository, we can still have some discussion on the updated draft (which should be available in the repository sometime next week). I would like any comments to be posted by November 26th, so that we can get an updated version out for WGLC the first week of December. Mary. -----Original Message----- From: Barnes, Mary [NGC:B602:EXCH] Sent: Tuesday, November 12, 2002 3:21 PM To: 'midcom@ietf.org' Subject: [midcom] Updated Protocol evaluation document available Hi all, We (David H., Juergen and myself) have completed the task of updating the SNMP section per the feedback from the IESG. Thanks to David Harrington for providing his expertise in this area. The following summarizes the changes: - Section 1.1 has been expanded to provide more detail on the architectural aspects of SNMP and its applicability as the MIDCOM protocol. - For Section 2, the Item level compliancies, which had been quite general statements, now contain quite a bit more detail on the aspects of SNMP which satisfy the requirement. - In the conclusion, the "counts" were updated as the updated evaluation resulted in 2.2.3, 2.2.5 and 2.2.6 being changed from P+ to T. - The conclusion text for SNMP was also updated. - References for SNMP were updated To facilitate the task of re-reviewing the document, I have put a Microsoft word version of the document which has the changes marked on my server at: http://home.attbi.com/~mbarnes42/IETF/draft-ietf-midcom-protocol-eval-06-v0- 3-w-chgs.doc The word version, with the changes incorporated, which also contains minor editorial changes necessary to generate the appropriate text format of the document (and some other editorial nits) is also on the server: http://home.attbi.com/~mbarnes42/IETF/draft-ietf-midcom-protocol-eval-06-v0- 3.doc The text version, which will be submitted to the repository the week of the IETF-55 meeting, is also on the server: http://home.attbi.com/~mbarnes42/IETF/draft-ietf-midcom-protocol-eval-06.txt Note, that I did a few other edits not related to SNMP while I was updating the document: - Updated the conclusion text for RSIP to reflect WG concensus wrt applicability as the MIDCOM protocol - Updated the MIDCOM references to include the RFC #s. - Updated the Diameter protocol reference. So, along with considering what's the next protocol to be eliminated, please do take time to review the updated document and provide feedback on the list. We will need to go through WGLC again and it would be nice to have the document ready right after the IETF-55 meeting. Regards, Mary H. Barnes mbarnes@nortelnetworks.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 Fri Nov 15 11:03:48 2002 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 LAA11246 for ; Fri, 15 Nov 2002 11:03:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFG5uZ30812 for midcom-archive@odin.ietf.org; Fri, 15 Nov 2002 11:05: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 gAFG1mv30713; Fri, 15 Nov 2002 11:01:48 -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 gAFFwXv30618 for ; Fri, 15 Nov 2002 10:58:33 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11083 for ; Fri, 15 Nov 2002 10:55:54 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAFFwTNf003684 for ; Fri, 15 Nov 2002 07:58:29 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAU87500; Fri, 15 Nov 2002 07:53:49 -0800 (PST) Message-Id: <200211151553.AAU87500@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Fri, 15 Nov 2002 10:58:27 -0500 Subject: [midcom] Agenda update: 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: , Because STUN was returned with comments, we'll be spending about 15 minutes on it during next week's meeting. That means that the agenda now looks something like: 5 min. Agenda-bashing 10 min. Status update Pre-midcom Protocol evaluation 15 min. STUN draft-ietf-midcom-stun-03.txt 15 min. Midcom protocol semantics draft-ietf-midcom-semantics-00.txt 5 min. Midcom protocol evaluation draft-ietf-midcom-protocol-eval-05.txt 10 min. Midcom protocol selection/process Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Nov 15 15:19:03 2002 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 PAA17965 for ; Fri, 15 Nov 2002 15:19:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFKLEs13499 for midcom-archive@odin.ietf.org; Fri, 15 Nov 2002 15:21:14 -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 gAFKHSv13014; Fri, 15 Nov 2002 15:17: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 gAFK8Vv12542 for ; Fri, 15 Nov 2002 15:08:31 -0500 Received: from dnsmx1pya.telcordia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17473 for ; Fri, 15 Nov 2002 15:05:44 -0500 (EST) Received: from notes800.cc.telcordia.com (notes800.cc.telcordia.com [128.96.79.6]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id PAA26642 for ; Fri, 15 Nov 2002 15:02:37 -0500 (EST) Subject: Re: [midcom] STUN issues - Processing Binding Response clarification To: midcom@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Panayiotis A. Thermos" Date: Fri, 15 Nov 2002 15:05:32 -0500 X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at 11/15/2002 03:02:38 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Greetings to all. I apologize if this has been discussed before. The draft states the following (section 9.4-Processing Binding Responses, page 18, third paragraph ) " If the response is a Binding Response, the client SHOULD check the response for a MESSAGE-INTEGRITY attribute. If not present, and the client placed a MESSAGE-INTEGRITY attribute into the request, it MUST discard the response." In the case where the client sends a binding "change-IP" and "change-port" request with a MESSAGE-INTEGRITY attribute, the server (e.g. server A) will forward the request to another STUN server (e.g. server B) which in turn will respond to the client's request. The later server (B) may not include a MESSAGE-INTEGRITY attribute in it's response thus the client will discard the response. And even if server B includes a MESSAGE-INTEGRITY attribute, it will be wrong and thus the client will discard the response. Perhaps the draft should incorporate that STUN server A should notify server B not to calculate its own SHA1 but use server's A MESSAGE-INTEGRITY attribute instead in this case. The notifications can be done through the FLAGS attribute (e.g. a re-use attribute flag "REUSE-ATTRIBUTE" with value "MESSAGE-INTEGRITY"). Peter Thermos Melinda Shore cc: (bcc: Panayiotis A. Thermos/Telcordia) Subject: [midcom] STUN issues 11/14/2002 08:32 AM The STUN document (http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-03.txt) has come back from IESG review with comments that need to be addressed. Thanks to the excellent new document tracker you can take a look at the comments yourself - find the document and click on the "DETAIL" button. The comments are listed in the "Comment log" and you can look at the individual comments, or you can look at the ballot and discussion summary by clicking the "Available" link in the "Detail Info" box at the top of the page (I had to ask for help finding that one, myself). Note that the summary does *not* include the most recent entry in the comment log. Specific issues include 1) miscellaneous wordsmithing - places where the text is unclear 2) a request to restructure return codes and rethink some of the error handling 3) improve our use of the FLAGS attribute 4) more explicit mention of the desirability of having STUN servers topologically "near" the endpoint with which we're communicating 5) modification of use of the RESPONSE-ADDRESS to protect against reflector attacks 6) a suggestion from one of the security ADs to forgo the use of client certs, along with a proposal for stateless authentication 7) a suggestion that this is one case where we don't want v6 compatibility and that the use of AAAA records should be removed Most of this can be handled through editing, but as a group we do need to: 1) accept or reject the authentication proposal 2) fix the FLAGS attribute 3) deal with the return codes issue 4) deal with the RESPONSE-ADDRESS issue We will be discussing this in Atlanta, but as always, the substance of our work happens here, on the mailing list. 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 Tue Nov 19 02:43:08 2002 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 CAA28240 for ; Tue, 19 Nov 2002 02:43:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJ7jPu30899 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 02:45: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 gAJ7fGv30752; Tue, 19 Nov 2002 02:41: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 gAJ7cMv30630 for ; Tue, 19 Nov 2002 02:38:22 -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 CAA28051 for ; Tue, 19 Nov 2002 02:35:34 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAJ7cEYH003032 for ; Tue, 19 Nov 2002 02:38:14 -0500 (EST) Message-ID: <3DD9EA63.70808@dynamicsoft.com> Date: Tue, 19 Nov 2002 02:38:11 -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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] STUN issue 1: response codes 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 Folks, As Melinda pointed out, there were several comments from IESG that require fixing in STUN. A few probably merit group discussion. I will be sending a separate email on each of those, proposing my solution, and will also discuss tomorrow. The first issue is response code handling. STUN specifies a new structure, using explicitly defined class and code values. This is similar to, but deviates from, more conventional three-digit reporting used in SMTP, SIP, HTTP and others. The IESG comment was that we should align here. I am inclined to agree. So, I propose we revert to a standard three digit code, and define the specific 400 class response codes we need. We also define the 500 class, but don't populate it with any respaonse codes, for potential future use. We ignore the 300 and 600 classes, as they are not applicable to STUN (anywya the usage of 300 class responses differs between SMTP and SIP/HTTP, so best to stay away from that...) Anyone object? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 02:57:14 2002 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 CAA28381 for ; Tue, 19 Nov 2002 02:57:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJ7xWS31256 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 02:59:32 -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 gAJ7u4v31182; Tue, 19 Nov 2002 02:56: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 gAJ7rPv31113 for ; Tue, 19 Nov 2002 02:53:25 -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 CAA28332 for ; Tue, 19 Nov 2002 02:50:37 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAJ7rGYH003036 for ; Tue, 19 Nov 2002 02:53:16 -0500 (EST) Message-ID: <3DD9EDEA.1040406@dynamicsoft.com> Date: Tue, 19 Nov 2002 02:53:14 -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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] stun issue #2: unknown attribute handling 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 STUN specification says that a server which doesn't understand an attribute with value over 0x7fff should discard the message. However, the client will retransmit it, not knowing that it was discarded because of this bad attribute. Some error reporting is needed. Proposal: add a 420 response code, and add an attribute that lists the attributes that weren't supported. This is similar to the Unsupported header in sip. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 03:04:05 2002 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 DAA28497 for ; Tue, 19 Nov 2002 03:04:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJ86MO31469 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 03:06:22 -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 gAJ82vv31406; Tue, 19 Nov 2002 03:02:57 -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 gAJ80cv31326 for ; Tue, 19 Nov 2002 03:00:38 -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 CAA28420 for ; Tue, 19 Nov 2002 02:57:50 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAJ80UYH003040 for ; Tue, 19 Nov 2002 03:00:30 -0500 (EST) Message-ID: <3DD9EF9B.7010905@dynamicsoft.com> Date: Tue, 19 Nov 2002 03:00:27 -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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] STUN issue #3: FLAG extensibility 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 STUN spec has a flag attribute which is a fixed 32 bits. Once we run out, thats it. The IESG had asked if this can be made extensible. Proposal: Add an "E" flag which, when one, adds another 32 bits of flags. Of course, that additional 32 bits also has "E", so there is unlimited flags. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 03:15:18 2002 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 DAA28814 for ; Tue, 19 Nov 2002 03:15:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJ8HZM32427 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 03:17:35 -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 gAJ8EAv32245; Tue, 19 Nov 2002 03:14:10 -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 gAJ84ov31441 for ; Tue, 19 Nov 2002 03:04:50 -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 DAA28460 for ; Tue, 19 Nov 2002 03:02:01 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAJ84fYH003043 for ; Tue, 19 Nov 2002 03:04:41 -0500 (EST) Message-ID: <3DD9F097.8000308@dynamicsoft.com> Date: Tue, 19 Nov 2002 03:04:39 -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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] STUN issue #4: IANA procedures 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 IESG commented that there were no IANA procedures defined for registering new attributes, messages, etc. Proposal: history shows that protocols that are often extended even when not originally intended. As such, we should prepare for this better, and therefore, define an iana registry for (1) messages, (2) resposne codes, (3) attributes, (4) flags. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 03:30:40 2002 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 DAA28989 for ; Tue, 19 Nov 2002 03:30:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJ8Wwj00492 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 03:32:58 -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 gAJ8TPv00359; Tue, 19 Nov 2002 03:29:25 -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 gAJ8N5v32605 for ; Tue, 19 Nov 2002 03:23:05 -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 DAA28880 for ; Tue, 19 Nov 2002 03:20:17 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAJ8MuYH003053 for ; Tue, 19 Nov 2002 03:22:56 -0500 (EST) Message-ID: <3DD9F4DE.6030207@dynamicsoft.com> Date: Tue, 19 Nov 2002 03:22:54 -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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] STUN issue #5: reflector attacks 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 STUN has a RESPONSE-ADDRESS attribute. This attribute is used by the client to tell the server the IP/port where to send the response. This can be used by an attacker as a reflector attack, to mask the true source IP address of a dos attack. Steve Bellovin suggested that this is best dealt with by adding, to the response, the source IP where the request came from, and to make sure its integrity protected. This adds traceability. So, you can't prevent this, but you can see the true source address. The proposal is to accept his recommendation and add a REFLECTED-FROM attribute containing this source address. Note that this source address can't actually be the one from the UDP request (since thats easily spoofed). But rather, from the TLS exchange that established the USERNAME used in the request. That requires state in the server, OR a smart implementation which creates usernames that contain this IP, along with an hmac over them to protect it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 03:36:17 2002 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 DAA29076 for ; Tue, 19 Nov 2002 03:36:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJ8cYK01299 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 03:38: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 gAJ8W2v00449; Tue, 19 Nov 2002 03:32:02 -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 gAJ8RYv32735 for ; Tue, 19 Nov 2002 03:28:15 -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 DAA28923 for ; Tue, 19 Nov 2002 03:24:35 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAJ8REYH003057 for ; Tue, 19 Nov 2002 03:27:14 -0500 (EST) Message-ID: <3DD9F5E0.1080405@dynamicsoft.com> Date: Tue, 19 Nov 2002 03:27:12 -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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] STUN issue #6: Client certs considered harmful 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 STUN allows for a client to present certificates in the TLS exchange, at MAY strength. However, this provides no value at all, since the server doesn't need to authenticate the client. In fact, it is harmful, because it introduces a way to impose computational load on the server. The proposal is to change use of client authentication to MUST NOT. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 03:41:24 2002 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 DAA29194 for ; Tue, 19 Nov 2002 03:41:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJ8hgD01545 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 03:43:42 -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 gAJ8b9v00815; Tue, 19 Nov 2002 03:37: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 gAJ8Ymv00578 for ; Tue, 19 Nov 2002 03:34:48 -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 DAA29026 for ; Tue, 19 Nov 2002 03:31:59 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAJ8YdYH003060 for ; Tue, 19 Nov 2002 03:34:39 -0500 (EST) Message-ID: <3DD9F79D.3090403@dynamicsoft.com> Date: Tue, 19 Nov 2002 03:34:37 -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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] STUN issue #7: recommended stateless server procedures 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 STUN specification doesn't give any specific algorithm for doing a stateless server. Stateless operation requires some way to hand out usernames and passwords without storing them. Since it is easy to do this wrong, Steve Bellovin recommedned an algorithm. The algorithm also allows for determination of the source IP address used for the TLS exchange, needed to handle another one of the open issues. His algorithm is: username = where prefix is some string (I honestly don't know what this is needed for - I have a note in asking him), rounded-time is the time rounded off, clientIP is the IP address where the TLS exchange came from, and hmac is the hmac over the prefix, rounded-time and client IP, using a server key. password = This allows the server to verify the password against the username, determine the staleness of the username, and determine the client IP used in the TLS exchange, all without state. I recommend we document this algorithm in the spec. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 03:42:15 2002 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 DAA29262 for ; Tue, 19 Nov 2002 03:42:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJ8iXv01622 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 03:44:33 -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 gAJ8f9v01455; Tue, 19 Nov 2002 03:41: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 gAJ8cxv01329 for ; Tue, 19 Nov 2002 03:38:59 -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 DAA29072 for ; Tue, 19 Nov 2002 03:36:11 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAJ8coYH003066 for ; Tue, 19 Nov 2002 03:38:51 -0500 (EST) Message-ID: <3DD9F898.90200@dynamicsoft.com> Date: Tue, 19 Nov 2002 03:38:48 -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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] STUN issue #8: IPv6 support considered harmful 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 Yes, you read the subject correctly. One of the IESG objected to IPv6 support in STUN. Although I personally think v6 will cause the proliferation of NAT, I suspect this is a non-debatable issue, and recommend removal of v6 support. That manifests itself in the DNS procedures, which allow AAAA records, and in the address families, which support IPv6. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 03:48:13 2002 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 DAA29338 for ; Tue, 19 Nov 2002 03:48:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJ8oVp01925 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 03:50: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 gAJ8l4v01744; Tue, 19 Nov 2002 03:47: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 gAJ8iJv01600 for ; Tue, 19 Nov 2002 03:44:19 -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 DAA29214 for ; Tue, 19 Nov 2002 03:41:30 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAJ8iAYH003070 for ; Tue, 19 Nov 2002 03:44:10 -0500 (EST) Message-ID: <3DD9F9D7.9010605@dynamicsoft.com> Date: Tue, 19 Nov 2002 03:44:07 -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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] STUN issue #9: Discard flag broken 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 One of the IESG questioned the usage of the discard flag. Little is said about it in the spec. I recall it was for supporting "suicide" packets meant to prime the nat to create a binding. I was going to tell them that, when I realized it doesnt work. It doesnt work because the creation of the binding needs to be done reliably. That is, the client needs to know whether the binding was created or not. To know that, it needs to know that its request passed through the nat. The only way it can know that is if the stun server sends a response. Thus, the request cannot be discarded. Since the flag was really only saving some overhead of sending a response, I propose we just discard the discard flag. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 06:26:23 2002 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 GAA01839 for ; Tue, 19 Nov 2002 06:26:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJBSWc10004 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 06:28:32 -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 gAJBP6v09931; Tue, 19 Nov 2002 06:25: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 gAJBKGv09799 for ; Tue, 19 Nov 2002 06:20:16 -0500 Received: from carbon.btinternet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01734 for ; Tue, 19 Nov 2002 06:17:30 -0500 (EST) Received: from host213-123-45-151.in-addr.btopenworld.com ([213.123.45.151] helo=tkw) by carbon.btinternet.com with smtp (Exim 3.22 #15) id 18E6QH-00031Y-00; Tue, 19 Nov 2002 11:20:06 +0000 Message-ID: <003b01c28fbd$a2ce1180$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" , References: <3DD9EF9B.7010905@dynamicsoft.com> Subject: Re: [midcom] STUN issue #3: FLAG extensibility Date: Tue, 19 Nov 2002 10:50:53 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 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 Jonathan, There should not be a need for this type of method as the TLV encoding of the parameter can tell you how many flags words there are. However, the spec could mention that there could be more than one word worth of flags. Pete. ----- Original Message ----- From: "Jonathan Rosenberg" To: Sent: 19 November 2002 08:00 Subject: [midcom] STUN issue #3: FLAG extensibility > The STUN spec has a flag attribute which is a fixed 32 bits. Once we run > out, thats it. The IESG had asked if this can be made extensible. > > Proposal: Add an "E" flag which, when one, adds another 32 bits of > flags. Of course, that additional 32 bits also has "E", so there is > unlimited flags. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > 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 Nov 19 06:27:37 2002 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 GAA01865 for ; Tue, 19 Nov 2002 06:27:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJBTkJ10089 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 06:29: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 gAJBN1v09875; Tue, 19 Nov 2002 06:23:01 -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 gAJBKCv09791 for ; Tue, 19 Nov 2002 06:20:12 -0500 Received: from carbon.btinternet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01736 for ; Tue, 19 Nov 2002 06:17:31 -0500 (EST) Received: from host213-123-45-151.in-addr.btopenworld.com ([213.123.45.151] helo=tkw) by carbon.btinternet.com with smtp (Exim 3.22 #15) id 18E6QJ-00031Y-00; Tue, 19 Nov 2002 11:20:07 +0000 Message-ID: <003c01c28fbd$a3b16ca0$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" , References: <3DD9EA63.70808@dynamicsoft.com> Subject: Re: [midcom] STUN issue 1: response codes Date: Tue, 19 Nov 2002 11:13:26 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 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 I agree the IESG's proposal that the codes should be broken down into what should happen next (e.g. retry, give up etc) rather than what caused them. However, as STUN is binary and SMTP etc are text, I don't think this implies that they need to use the regular text based 3 digit code. (The format is really already aligned, but just uses a more binary friendly base 256 instead of base 10.) From a debug point of view, it's probably easier for someone to look at the current class based scheme rather than having to work out that 0x1A4 is a class 400 error. (I would prefer to see the class codes divided by 100, e.g. 400 -> 4, 500 -> 5 etc.) Still, dividing by 10 is no great hardship nowadays, so if it keeps people happy, it's OK by me. Pete. ----- Original Message ----- From: "Jonathan Rosenberg" To: Sent: 19 November 2002 07:38 Subject: [midcom] STUN issue 1: response codes > Folks, > > As Melinda pointed out, there were several comments from IESG that > require fixing in STUN. A few probably merit group discussion. I will be > sending a separate email on each of those, proposing my solution, and > will also discuss tomorrow. > > The first issue is response code handling. STUN specifies a new > structure, using explicitly defined class and code values. This is > similar to, but deviates from, more conventional three-digit reporting > used in SMTP, SIP, HTTP and others. The IESG comment was that we should > align here. > > I am inclined to agree. So, I propose we revert to a standard three > digit code, and define the specific 400 class response codes we need. We > also define the 500 class, but don't populate it with any respaonse > codes, for potential future use. We ignore the 300 and 600 classes, as > they are not applicable to STUN (anywya the usage of 300 class responses > differs between SMTP and SIP/HTTP, so best to stay away from that...) > > Anyone object? > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > 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 Nov 19 09:33:57 2002 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 JAA06328 for ; Tue, 19 Nov 2002 09:33:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJEa7W21170 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 09:36: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 gAJEWMv21053; Tue, 19 Nov 2002 09:32: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 gAJETMv20956 for ; Tue, 19 Nov 2002 09:29:22 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06231 for ; Tue, 19 Nov 2002 09:26:41 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gAJET3u4011437; Tue, 19 Nov 2002 06:29:03 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAV79702; Tue, 19 Nov 2002 06:24:30 -0800 (PST) Message-Id: <200211191424.AAV79702@mira-sjc5-4.cisco.com> To: Jonathan Rosenberg cc: midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] STUN issue #4: IANA procedures In-Reply-To: Message from Jonathan Rosenberg of "Tue, 19 Nov 2002 03:04:39 EST." <3DD9F097.8000308@dynamicsoft.com> Date: Tue, 19 Nov 2002 09:29:06 -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: , > Proposal: history shows that protocols that are often extended even when > not originally intended. As such, we should prepare for this better, and > therefore, define an iana registry for (1) messages, (2) resposne codes, > (3) attributes, (4) flags. I am unenthusiastic about this. From talking with various implementers it's pretty clear that even though the protocol isn't standardized yet and even though we're clear (are we not?) that this is to be a short-lived protocol and that it has a number of serious limitations that make it unsuitable for longer-term use, we're already looking at feature creep. I'd really like to discourage this or, at least, avoid suggesting that the working group thinks this is a good thing. If somebody wants to talk about the need to have a reasonable mechanism for fixing errors that are discovered in the future that's reasonable, but extending STUN? That's a problem. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 10:48:53 2002 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 KAA07930 for ; Tue, 19 Nov 2002 10:48:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJFp4o26196 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 10:51: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 gAJFiDv25835; Tue, 19 Nov 2002 10:44: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 gAJFf2v25723 for ; Tue, 19 Nov 2002 10:41:02 -0500 Received: from protactinium (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07755 for ; Tue, 19 Nov 2002 10:38:15 -0500 (EST) Received: from host62-6-72-167.in-addr.btopenworld.com ([62.6.72.167] helo=tkw) by protactinium with smtp (Exim 3.22 #15) id 18EAUL-0001Ct-00; Tue, 19 Nov 2002 15:40:33 +0000 Message-ID: <001d01c28fe1$f02eaec0$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" , "Melinda Shore" Cc: References: <200211191424.AAV79702@mira-sjc5-4.cisco.com> Subject: Re: [midcom] STUN issue #4: IANA procedures Date: Tue, 19 Nov 2002 15:38:25 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 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 I'm inclined to agree with you Melinda. (When I did SPAN I ripped most of the extensibility stuff out of it for this reason.) I don't see why we can't define such procedures as and when they become necessary - hopefully they won't - in a separate RFC (or a STUN v2 if required). That should raise the barrier for minor extensions that are feature creep with little merit. In other words, it would mean that it would require significant group consensus before the changes could be made. Pete. ----- Original Message ----- From: "Melinda Shore" To: "Jonathan Rosenberg" Cc: Sent: 19 November 2002 14:29 Subject: Re: [midcom] STUN issue #4: IANA procedures > > Proposal: history shows that protocols that are often extended even when > > not originally intended. As such, we should prepare for this better, and > > therefore, define an iana registry for (1) messages, (2) resposne codes, > > (3) attributes, (4) flags. > > I am unenthusiastic about this. From talking with various > implementers it's pretty clear that even though the protocol > isn't standardized yet and even though we're clear (are we > not?) that this is to be a short-lived protocol and that it > has a number of serious limitations that make it unsuitable > for longer-term use, we're already looking at feature > creep. I'd really like to discourage this or, at least, > avoid suggesting that the working group thinks this is a > good thing. > > If somebody wants to talk about the need to have a > reasonable mechanism for fixing errors that are discovered > in the future that's reasonable, but extending STUN? That's > a problem. > > 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 Nov 19 11:19:52 2002 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 LAA08704 for ; Tue, 19 Nov 2002 11:19:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJGM3q28152 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 11:22:03 -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 gAJGF8v27890; Tue, 19 Nov 2002 11:15: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 gAJG8iv27616 for ; Tue, 19 Nov 2002 11:08:44 -0500 Received: from zctfs063.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08316 for ; Tue, 19 Nov 2002 11:05:55 -0500 (EST) Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAJG8KT16442; Tue, 19 Nov 2002 17:08:20 +0100 (MET) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Nov 2002 17:08:17 +0100 Message-ID: From: "Cedric Aoun" To: "'Juergen Quittek'" , "'Martin Stiemerling'" , midcom@ietf.org Cc: "Louis-Nicolas Hamer" , "Kwok-Ho Chan" Subject: RE: [midcom] Winnowing down the list Date: Tue, 19 Nov 2002 17:08:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28FE5.DF166FAC" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C28FE5.DF166FAC Content-Type: text/plain; charset="iso-8859-1" Hi, Here is a small memo on how COPS-PR manages the directionality and policy rule contention (many Midcom agents manipulating the same policy rule). In this memo, COPS = COPS-PR The first thing is to look at the applicability of off path Middle box control, it applies to simple network topology where the Midcom agent has awareness of the end points and the Middlebox connected to their network. Brief walk thru on establishing communications between the Midcom agent and the Middlebox, and the directionality requirement ------------------- The MIDCOM agent and the Middlebox need to setup a trust relationship which comprises of provisioning authorization policies on the Middlebox on which Midcom agent is allowed to request MIDCOM policy rule installation. In addition a security association is setup, in the case of COPS IPSEC ESP is the preferred way, the MIDCOM agent sends the initial key management protocol message (IKE or other). Once the security association is up, the Middlebox establishes a TCP connection with the Midcom agent, and send sends the COPS open message (I won't go in much details in this note). When the Midcom agents requests a policy rule installation, it will send an UNSOLLICITED COPS message etc ... This behavior is compliant to the current COPS specification, as well as to the requirement relevant to the establishment of communications between the Middlebox and Midcom agent. Handling resource contention happening due to manipulation of policy rules by several Midcom agents ----- In all protocol implementations, a resource coordination or management function is required on the host to be able to handle resource contention. The interaction between the COPS state machine and the resource management function is quite simple, I didn't add it in this "brief" note, but could do so in another separate mail if requested. I have added some practicality in these walk thrus to show that this is real and how is works with the current COPS specification, note that I tried to keep it as simple as I can for readers not familiar with COPS. The COPS PEP will establish a TCP connection (following the setup phase as discussed above) to each MA, the PEP establishes a COPS "connection" to each MA, each using a different Client-Type, in this case MIDCOM_1, MIDCOM_2, MIDCOM_3. (Note that a single PEP can not have multiple COPS connections with the same Client-Type (with the exception of NULL Client-Type)). Hence the PEP must use a different Client-Type for each MA. One method is "Client-Type boot strapping". The PEP first performs a COPS OPEN with the well know (standardized) Client-Type of MIDCOM, using this COPS connection to indicate to the MA that it will follow up with a second COPS OPEN with a specific none standardized Client-Type (MIDCOM_1). It is the second COPS connection that will be used for the real MIDCOM communication. This is very much like the way well known port numbers are used for the initial TCP connection request, with the actual TCP traffic handled using a different TCP port/process. Notice the Client-Type range used for MIDCOM_1 is in the none reserved range. And it is the MB that select the actual Client-Type to use. Hence there will not be collision of the same Client-Type used on a single MB. Hope this helps clarifying on the resolution of the raised issues on the list. In the sake of moving things forward on the protocol evaluation front, would the WG think that proposing implementation guides on protocol x (x being one of the remaining protocols in the list) being MIDCOM help in the selection process? We need to address as well the authorization policy area and see which protocol integrates best with authorization policy exchanges. Cheers Cedric -----Original Message----- From: Juergen Quittek [mailto:quittek@ccrle.nec.de] Sent: 12 November 2002 15:12 To: Aoun, Cedric [GOLF:MA01:EXCH]; 'Martin Stiemerling'; Hamer, Louis-Nicolas [CAR:AN22:EXCH] Cc: midcom@ietf.org Subject: RE: [midcom] Winnowing down the list Cedric, -- Cedric Aoun wrote on 12 November 2002 11:18 +0100: > Martin, > I believe that it is clearly stated in the protocol evaluation document that > several PDPs can access to the same resource by using an underlying resource > management function assisted with local policies. I think we have closed on > this > one before the previous IETF meeting. I agree, we have closed this issue as far as the text in the evaluation document is concerend. All protocols have several advantages and some problems. However, the evaluation document does neither weight the problems, nor does it give a recommendation concerning protocol selection. Therefore, we now have to enter the next stage. We have to weight the advantages and disadvantages of the protocols in order to get closer to a recommendation ot better: a protocol selection. And as far as I understand Martin, he is not aiming at changing any line in the evaluation, but at getting closer to a recommendation. One step in this direction is looking again at the disadvantages of the candidate protocols, which are described in the evaluation document. And then we have to find out for each of them, whether it is just a minor disadvantage or a serious problem. In the case you are discussing with Martin, I see at first glance technical problem that can be solved, but I am not happy with using COPS-PR while violating its specification in RFC 3084. RFC 3084 says: "There may be one or more PIBs for given area of policy and different areas of policy may have different sets of PIBs." (Section 1) So let's assume we have a Midcom PIB in the Midcom area. "Second, as it [COPS] has a single connection between the policy client and server per area of policy control identified by a COPS Client-Type, it guarantees only one server updates a particular policy configuration at any given time. Such a policy configuration is effectively locked, even from local console configuration, while the PEP is connected to a PDP via COPS." (Section 1.1) Conclusion: only a single Midcom agent would be allowed to request or release middlebox resources. I know that technically we could just ignore this and it works, but I do not feel comfortable when doing so. Support for doing so is given by "In order to support a model that includes multiple PDPs controlling non-overlapping areas of policy on a single PEP, the client-type specified by the PEP to the PDP is unique for the area of policy being managed. A single client-type for a given area of policy (e.g., QoS) will be used for all PIBs that exist in that area. The client should treat all the COPS-PR client-types it supports as non-overlapping and independent namespaces where instances MUST NOT be shared." (Section 1) So maybe we can map agent identfiers to client types and use a lot of existing COPS functonality. But still it leaves the impression of a hack rather than of a solution. Juergen > Cedric > > > -----Original Message----- > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > Sent: 12 November 2002 11:03 > To: Hamer, Louis-Nicolas [CAR:AN22:EXCH] > Cc: midcom@ietf.org > Subject: Re: [midcom] Winnowing down the list > > > > Louis-Nicolas Hamer wrote: > >> Melinda, all, >> > [....] > > >> >> The only reason invoked against COPS was the directionality requirement. >> Kwok explained in great lengths how this was not a big deal - it can be >> fixed quite easily. So I object to your proposal to remove COPS. > > > Hmm, there is another reason against COPS: > The COPS PEP is not able to receive configuration data from multiple PDP > for the *same* resource, e.g. the middlebox can not receive policy rule > configuration requests from different agents for the same packet filter > at the same time. > > Martin > > >> >> As I have indicated before, I think COPS, SNMP and MEGACO are very good >> fits for MIDCOM. >> I would suggest that the best way forward would be to see what the WG >> decides on the approach to take to >> "pinpoint" the best protocol to use - I believe you have >> that point on the agenda for the Atlanta meeting, right? >> >> l-n >> >> >> > -----Original Message----- >> > From: Melinda Shore [mailto:mshore@cisco.com] >> > Sent: Friday, November 08, 2002 4:51 PM >> > To: midcom@ietf.org >> > Subject: [midcom] Winnowing down the list >> > >> > >> > I'd like to continue to try to narrow the list of midcom >> > candidates. From the discussion so far it looks like a lot >> > of people are dubious about COPS, so here's the question: >> > >> > Is there any objection to removing COPS from the list of >> > candidate midcom protocols? If you object, please give a reason. >> > >> > 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 ------_=_NextPart_001_01C28FE5.DF166FAC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Winnowing down the list

Hi,
Here is a small memo on how COPS-PR manages the = directionality and policy rule contention (many Midcom agents = manipulating the same policy rule).

In this memo, COPS =3D COPS-PR

The first thing is to look at the applicability of = off path Middle box control, it applies to simple network topology = where the Midcom agent has awareness of the end points and the = Middlebox connected to their network.

Brief walk thru on establishing communications = between the Midcom agent and the Middlebox, and the directionality = requirement

-------------------
The MIDCOM agent and the Middlebox need to setup a = trust relationship which comprises of provisioning authorization = policies on the Middlebox on which Midcom agent is allowed to request = MIDCOM policy rule installation. In addition a security association is = setup, in the case of COPS IPSEC ESP is the preferred way, the MIDCOM = agent sends the initial key management protocol message (IKE or = other).

Once the security association is up, the Middlebox = establishes a TCP connection with the Midcom agent, and send sends the = COPS open message (I won't go in much details in this note). When the = Midcom agents requests a policy rule installation, it will send an = UNSOLLICITED COPS message etc ...

This behavior is compliant to the current COPS = specification, as well as to the requirement relevant to the = establishment of communications between the Middlebox and Midcom = agent.

Handling resource contention happening due to = manipulation of policy rules by several Midcom agents
-----
In all protocol implementations, a resource = coordination or management function is required on the host to be able = to handle resource contention.

The interaction between the COPS state machine and = the resource management function is quite simple, I didn't add it in = this "brief" note, but could do so in another separate mail = if requested.

I have added some practicality in these walk thrus to = show that this is real and how is works with the current COPS = specification, note that I tried to keep it as simple as I can for = readers not familiar with COPS.

The COPS PEP will establish a TCP connection = (following the setup phase as discussed above) to each MA, the PEP = establishes a COPS "connection"  to each MA, each using = a different Client-Type, in this case MIDCOM_1, MIDCOM_2, MIDCOM_3. = (Note that a single PEP can not have multiple COPS connections with the = same Client-Type (with the exception of NULL Client-Type)).

Hence the PEP must use a different Client-Type for = each MA.  One method is "Client-Type boot = strapping".  The PEP first performs a COPS OPEN with the well = know (standardized) Client-Type of MIDCOM, using this COPS connection = to indicate to the MA that it will follow up with a second COPS OPEN = with a specific none standardized Client-Type (MIDCOM_1).  It is = the second COPS connection that will be used for the real MIDCOM = communication.  This is very much like the way well known port = numbers are used for the initial TCP connection request, with the = actual TCP traffic handled using a different TCP port/process.

Notice the Client-Type range used for MIDCOM_1 is in = the none reserved range.  And it is the MB that select the actual = Client-Type to use.  Hence there will not be collision of the same = Client-Type used on a single MB.

Hope this helps clarifying on the resolution of the = raised issues on the list.

In the sake of moving things forward on the protocol = evaluation front, would the WG think that proposing implementation = guides on protocol x (x being one of the remaining protocols in the = list) being MIDCOM help in the selection process?  We need to = address as well the authorization policy area and see which protocol = integrates best with authorization policy exchanges.

Cheers
Cedric

-----Original Message-----
From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
Sent: 12 November 2002 15:12
To: Aoun, Cedric [GOLF:MA01:EXCH]; 'Martin = Stiemerling'; Hamer,
Louis-Nicolas [CAR:AN22:EXCH]
Cc: midcom@ietf.org
Subject: RE: [midcom] Winnowing down the list


Cedric,

-- Cedric Aoun wrote on 12 November 2002 11:18 = +0100:

> Martin,
> I believe that it is clearly stated in the = protocol evaluation document that
> several PDPs can access to the same resource by = using an underlying resource
> management function assisted with local = policies. I think we have closed on
> this
> one before the previous IETF meeting.

I agree, we have closed this issue as far as the text = in the evaluation
document is concerend. All protocols have several = advantages and some
problems. However, the evaluation document does = neither weight the problems,
nor does it give a recommendation concerning = protocol selection.

Therefore, we now have to enter the next stage. We = have to weight the
advantages and disadvantages of the protocols in = order to get closer to
a recommendation ot better: a protocol selection. = And as far as I
understand Martin, he is not aiming at changing any = line in the
evaluation, but at getting closer to a = recommendation.

One step in this direction is looking again at the = disadvantages of the
candidate protocols, which are described in the = evaluation document.
And then we have to find out for each of them, = whether it is just a minor
disadvantage or a serious problem.


In the case you are discussing with Martin, I see at = first glance technical
problem that can be solved, but I am not happy with = using COPS-PR while
violating its specification in RFC 3084.

RFC 3084 says:

    "There may be one or more = PIBs for given area of policy and
     different areas of policy = may have different sets of PIBs."
     (Section 1)

So let's assume we have a Midcom PIB in the Midcom = area.

    "Second, as it [COPS] has a = single connection between the
     policy client and server = per area of policy control identified
     by a COPS Client-Type, it = guarantees only one server updates
     a particular policy = configuration at any given time.  Such a
     policy configuration is = effectively locked, even from local
     console configuration, = while the PEP is connected to a PDP
     via COPS." (Section = 1.1)

Conclusion: only a single Midcom agent would be = allowed to request
or release middlebox resources. I know that = technically we could just
ignore this and it works, but I do not feel = comfortable when doing so.

Support for doing so is given by

    "In order to support a model = that includes multiple PDPs
     controlling non-overlapping = areas of policy on a single PEP, the
     client-type specified by = the PEP to the PDP is unique for the area
     of policy being = managed.  A single client-type for a given area of
     policy (e.g., QoS) will be = used for all PIBs that exist in that
     area.  The client = should treat all the COPS-PR client-types it
     supports as non-overlapping = and independent namespaces where
     instances MUST NOT be = shared." (Section 1)

So maybe we can map agent identfiers to client types = and use a lot of
existing COPS functonality. But still it leaves the = impression of a
hack rather than of a solution.

    Juergen


> Cedric
>
>
> -----Original Message-----
> From: Martin Stiemerling [mailto:Martin.Stiemerlin= g@ccrle.nec.de]
> Sent: 12 November 2002 11:03
> To: Hamer, Louis-Nicolas [CAR:AN22:EXCH]
> Cc: midcom@ietf.org
> Subject: Re: [midcom] Winnowing down the = list
>
>
>
> Louis-Nicolas Hamer wrote:
>
>> Melinda, all,
>>
> [....]
>
>
>>
>> The only reason invoked against COPS was = the directionality requirement.
>> Kwok explained in great lengths how this = was not a big deal - it can be
>> fixed quite easily. So I object to your = proposal to remove COPS.
>
>
> Hmm, there is another reason against = COPS:
> The COPS PEP is not able to receive = configuration data from multiple PDP
> for the *same* resource, e.g. the middlebox can = not receive policy rule
> configuration requests from different agents = for the same packet filter
> at the same time.
>
> Martin
>
>
>>
>> As I have indicated before, I think COPS, = SNMP and MEGACO are very good
>> fits for MIDCOM.
>> I would suggest that the best way forward = would be to see what the WG
>> decides on the approach to take to
>> "pinpoint" the best protocol to = use - I believe you have
>> that point on the agenda for the Atlanta = meeting, right?
>>
>> l-n
>>
>>
>>  > -----Original = Message-----
>>  > From: Melinda Shore [mailto:mshore@cisco.com]
>>  > Sent: Friday, November 08, 2002 = 4:51 PM
>>  > To: midcom@ietf.org
>>  > Subject: [midcom] Winnowing down = the list
>>  >
>>  >
>>  > I'd like to continue to try to = narrow the list of midcom
>>  > candidates.  From the = discussion so far it looks like a lot
>>  > of people are dubious about = COPS, so here's the question:
>>  >
>>  > Is there any objection to = removing COPS from the list of
>>  > candidate midcom = protocols?  If you object, please give a reason.
>>  >
>>  > 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


------_=_NextPart_001_01C28FE5.DF166FAC-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 11:23:35 2002 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 LAA08805 for ; Tue, 19 Nov 2002 11:23:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJGPkQ28321 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 11:25: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 gAJGJ6v28037; Tue, 19 Nov 2002 11:19: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 gAJGGJv27946 for ; Tue, 19 Nov 2002 11:16:19 -0500 Received: from zctfs063.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08542 for ; Tue, 19 Nov 2002 11:13:25 -0500 (EST) Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAJGFoT17110; Tue, 19 Nov 2002 17:15:50 +0100 (MET) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Nov 2002 17:15:49 +0100 Message-ID: From: "Cedric Aoun" To: "'Juergen Quittek'" , "'Martin Stiemerling'" , "'midcom@ietf.org'" Cc: "Louis-Nicolas Hamer" , "Kwok-Ho Chan" Subject: RE: [midcom] Winnowing down the list Date: Tue, 19 Nov 2002 17:15:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28FE6.C452C908" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C28FE6.C452C908 Content-Type: text/plain; charset="iso-8859-1" hopefully you'll get the email this time, looks like the mail list server is having problems ... -----Original Message----- From: Aoun, Cedric [GOLF:MA01:EXCH] Sent: 19 November 2002 17:08 To: 'Juergen Quittek'; 'Martin Stiemerling'; midcom@ietf.org Cc: Hamer, Louis-Nicolas [CAR:AN22:EXCH]; Chan, Kwok-Ho [BL60:470:EXCH] Subject: RE: [midcom] Winnowing down the list Hi, Here is a small memo on how COPS-PR manages the directionality and policy rule contention (many Midcom agents manipulating the same policy rule). In this memo, COPS = COPS-PR The first thing is to look at the applicability of off path Middle box control, it applies to simple network topology where the Midcom agent has awareness of the end points and the Middlebox connected to their network. Brief walk thru on establishing communications between the Midcom agent and the Middlebox, and the directionality requirement ------------------- The MIDCOM agent and the Middlebox need to setup a trust relationship which comprises of provisioning authorization policies on the Middlebox on which Midcom agent is allowed to request MIDCOM policy rule installation. In addition a security association is setup, in the case of COPS IPSEC ESP is the preferred way, the MIDCOM agent sends the initial key management protocol message (IKE or other). Once the security association is up, the Middlebox establishes a TCP connection with the Midcom agent, and send sends the COPS open message (I won't go in much details in this note). When the Midcom agents requests a policy rule installation, it will send an UNSOLLICITED COPS message etc ... This behavior is compliant to the current COPS specification, as well as to the requirement relevant to the establishment of communications between the Middlebox and Midcom agent. Handling resource contention happening due to manipulation of policy rules by several Midcom agents ----- In all protocol implementations, a resource coordination or management function is required on the host to be able to handle resource contention. The interaction between the COPS state machine and the resource management function is quite simple, I didn't add it in this "brief" note, but could do so in another separate mail if requested. I have added some practicality in these walk thrus to show that this is real and how is works with the current COPS specification, note that I tried to keep it as simple as I can for readers not familiar with COPS. The COPS PEP will establish a TCP connection (following the setup phase as discussed above) to each MA, the PEP establishes a COPS "connection" to each MA, each using a different Client-Type, in this case MIDCOM_1, MIDCOM_2, MIDCOM_3. (Note that a single PEP can not have multiple COPS connections with the same Client-Type (with the exception of NULL Client-Type)). Hence the PEP must use a different Client-Type for each MA. One method is "Client-Type boot strapping". The PEP first performs a COPS OPEN with the well know (standardized) Client-Type of MIDCOM, using this COPS connection to indicate to the MA that it will follow up with a second COPS OPEN with a specific none standardized Client-Type (MIDCOM_1). It is the second COPS connection that will be used for the real MIDCOM communication. This is very much like the way well known port numbers are used for the initial TCP connection request, with the actual TCP traffic handled using a different TCP port/process. Notice the Client-Type range used for MIDCOM_1 is in the none reserved range. And it is the MB that select the actual Client-Type to use. Hence there will not be collision of the same Client-Type used on a single MB. Hope this helps clarifying on the resolution of the raised issues on the list. In the sake of moving things forward on the protocol evaluation front, would the WG think that proposing implementation guides on protocol x (x being one of the remaining protocols in the list) being MIDCOM help in the selection process? We need to address as well the authorization policy area and see which protocol integrates best with authorization policy exchanges. Cheers Cedric ------_=_NextPart_001_01C28FE6.C452C908 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Winnowing down the list

hopefully you'll get the email this time, looks like = the mail list server is having problems ...

-----Original Message-----
From: Aoun, Cedric [GOLF:MA01:EXCH]
Sent: 19 November 2002 17:08
To: 'Juergen Quittek'; 'Martin Stiemerling'; = midcom@ietf.org
Cc: Hamer, Louis-Nicolas [CAR:AN22:EXCH]; Chan, = Kwok-Ho [BL60:470:EXCH]
Subject: RE: [midcom] Winnowing down the list


Hi,
Here is a small memo on how COPS-PR manages the = directionality and policy rule contention (many Midcom agents = manipulating the same policy rule).

In this memo, COPS =3D COPS-PR

The first thing is to look at the applicability of = off path Middle box control, it applies to simple network topology = where the Midcom agent has awareness of the end points and the = Middlebox connected to their network.

Brief walk thru on establishing communications = between the Midcom agent and the Middlebox, and the directionality = requirement

-------------------
The MIDCOM agent and the Middlebox need to setup a = trust relationship which comprises of provisioning authorization = policies on the Middlebox on which Midcom agent is allowed to request = MIDCOM policy rule installation. In addition a security association is = setup, in the case of COPS IPSEC ESP is the preferred way, the MIDCOM = agent sends the initial key management protocol message (IKE or = other).

Once the security association is up, the Middlebox = establishes a TCP connection with the Midcom agent, and send sends the = COPS open message (I won't go in much details in this note). When the = Midcom agents requests a policy rule installation, it will send an = UNSOLLICITED COPS message etc ...

This behavior is compliant to the current COPS = specification, as well as to the requirement relevant to the = establishment of communications between the Middlebox and Midcom = agent.

Handling resource contention happening due to = manipulation of policy rules by several Midcom agents
-----
In all protocol implementations, a resource = coordination or management function is required on the host to be able = to handle resource contention.

The interaction between the COPS state machine and = the resource management function is quite simple, I didn't add it in = this "brief" note, but could do so in another separate mail = if requested.

I have added some practicality in these walk thrus to = show that this is real and how is works with the current COPS = specification, note that I tried to keep it as simple as I can for = readers not familiar with COPS.

The COPS PEP will establish a TCP connection = (following the setup phase as discussed above) to each MA, the PEP = establishes a COPS "connection"  to each MA, each using = a different Client-Type, in this case MIDCOM_1, MIDCOM_2, MIDCOM_3. = (Note that a single PEP can not have multiple COPS connections with the = same Client-Type (with the exception of NULL Client-Type)).

Hence the PEP must use a different Client-Type for = each MA.  One method is "Client-Type boot strapping".&nbs= p; The PEP first performs a COPS OPEN with the well know (standardized) = Client-Type of MIDCOM, using this COPS connection to indicate to the MA = that it will follow up with a second COPS OPEN with a specific none = standardized Client-Type (MIDCOM_1).  It is the second COPS = connection that will be used for the real MIDCOM communication.  = This is very much like the way well known port numbers are used for the = initial TCP connection request, with the actual TCP traffic handled = using a different TCP port/process.

Notice the Client-Type range used for MIDCOM_1 is in = the none reserved range.  And it is the MB that select the actual = Client-Type to use.  Hence there will not be collision of the same = Client-Type used on a single MB.

Hope this helps clarifying on the resolution of the = raised issues on the list.

In the sake of moving things forward on the protocol = evaluation front, would the WG think that proposing implementation = guides on protocol x (x being one of the remaining protocols in the = list) being MIDCOM help in the selection process?  We need to = address as well the authorization policy area and see which protocol = integrates best with authorization policy exchanges.

Cheers
Cedric

------_=_NextPart_001_01C28FE6.C452C908-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 11:36:22 2002 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 LAA09213 for ; Tue, 19 Nov 2002 11:36:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJGcXj29385 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 11:38:33 -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 gAJGZ6v28675; Tue, 19 Nov 2002 11:35: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 gAJGVYv28536 for ; Tue, 19 Nov 2002 11:31:34 -0500 Received: from dgesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08970 for ; Tue, 19 Nov 2002 11:28:52 -0500 (EST) Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.wcom.com (Iplanet MTA) with ESMTP id <0H5U0035M0HGW0@firewall.wcom.com> for midcom@ietf.org; Tue, 19 Nov 2002 16:29:40 +0000 (GMT) Received: from dgismtp06.wcomnet.com by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H5U00J010HD13@dgismtp06.wcomnet.com>; Tue, 19 Nov 2002 16:29:37 +0000 (GMT) Received: from ws041v4569 ([166.34.120.128]) by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H5U00H9A0HCZO@dgismtp06.wcomnet.com>; Tue, 19 Nov 2002 16:29:37 +0000 (GMT) Date: Tue, 19 Nov 2002 10:29:37 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] STUN issue #6: Client certs considered harmful In-reply-to: <3DD9F5E0.1080405@dynamicsoft.com> To: "'Jonathan Rosenberg'" , midcom@ietf.org Message-id: <002301c28fe8$da6a0100$807822a6@ws041v4569> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-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 Why wouldn't we want the client to authenticate? I would think that this a requirement. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Tuesday, November 19, 2002 2:27 AM To: midcom@ietf.org Subject: [midcom] STUN issue #6: Client certs considered harmful STUN allows for a client to present certificates in the TLS exchange, at MAY strength. However, this provides no value at all, since the server doesn't need to authenticate the client. In fact, it is harmful, because it introduces a way to impose computational load on the server. The proposal is to change use of client authentication to MUST NOT. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org 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 Nov 19 11:36:24 2002 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 LAA09226 for ; Tue, 19 Nov 2002 11:36:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJGcaG29398 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 11:38: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 gAJGW3v28551; Tue, 19 Nov 2002 11:32: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 gAJGT5v28437 for ; Tue, 19 Nov 2002 11:29:05 -0500 Received: from dgesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08883 for ; Tue, 19 Nov 2002 11:26:23 -0500 (EST) Received: from dgismtp05.wcomnet.com ([166.38.58.88]) by firewall.wcom.com (Iplanet MTA) with ESMTP id <0H5U0032N0EJS4@firewall.wcom.com> for midcom@ietf.org; Tue, 19 Nov 2002 16:27:55 +0000 (GMT) Received: from dgismtp05.wcomnet.com by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H5U00J010EJMF@dgismtp05.wcomnet.com>; Tue, 19 Nov 2002 16:27:55 +0000 (GMT) Received: from ws041v4569 ([166.34.120.128]) by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H5U00I5S0EIRI@dgismtp05.wcomnet.com>; Tue, 19 Nov 2002 16:27:54 +0000 (GMT) Date: Tue, 19 Nov 2002 10:27:55 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] STUN issue #5: reflector attacks In-reply-to: <3DD9F4DE.6030207@dynamicsoft.com> To: "'Jonathan Rosenberg'" , midcom@ietf.org Message-id: <002001c28fe8$9d648370$807822a6@ws041v4569> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-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 Fully agree! -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Tuesday, November 19, 2002 2:23 AM To: midcom@ietf.org Subject: [midcom] STUN issue #5: reflector attacks STUN has a RESPONSE-ADDRESS attribute. This attribute is used by the client to tell the server the IP/port where to send the response. This can be used by an attacker as a reflector attack, to mask the true source IP address of a dos attack. Steve Bellovin suggested that this is best dealt with by adding, to the response, the source IP where the request came from, and to make sure its integrity protected. This adds traceability. So, you can't prevent this, but you can see the true source address. The proposal is to accept his recommendation and add a REFLECTED-FROM attribute containing this source address. Note that this source address can't actually be the one from the UDP request (since thats easily spoofed). But rather, from the TLS exchange that established the USERNAME used in the request. That requires state in the server, OR a smart implementation which creates usernames that contain this IP, along with an hmac over them to protect it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org 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 Nov 19 13:10:48 2002 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 NAA11670 for ; Tue, 19 Nov 2002 13:10:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJID0602973 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 13:13:00 -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 gAJI6Cv01765; Tue, 19 Nov 2002 13:06: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 gAJI3uv01656 for ; Tue, 19 Nov 2002 13:03:56 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11259 for ; Tue, 19 Nov 2002 13:01:12 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gAJI3MsA009016; Tue, 19 Nov 2002 10:03:22 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAV86097; Tue, 19 Nov 2002 09:58:57 -0800 (PST) Message-Id: <200211191758.AAV86097@mira-sjc5-4.cisco.com> To: "Christopher A. Martin" cc: "'Jonathan Rosenberg'" , midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] STUN issue #6: Client certs considered harmful In-Reply-To: Message from "Christopher A. Martin" of "Tue, 19 Nov 2002 10:29:37 CST." <002301c28fe8$da6a0100$807822a6@ws041v4569> Date: Tue, 19 Nov 2002 13:03:32 -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: , Could you describe what you'd be protecting against by having the client authenticated by the server? Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 13:19:06 2002 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 NAA11930 for ; Tue, 19 Nov 2002 13:19:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJILHS03477 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 13:21: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 gAJIHfv03191; Tue, 19 Nov 2002 13:17:41 -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 gAJIDEv03013 for ; Tue, 19 Nov 2002 13:13:14 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11668 for ; Tue, 19 Nov 2002 13:10:30 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAJID3Nf022251; Tue, 19 Nov 2002 10:13:03 -0800 (PST) Received: from CSCOAMERA10416 (sjc-vpn1-371.cisco.com [10.21.97.115]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.0-GA) with ESMTP id ABO96945; Tue, 19 Nov 2002 10:12:42 -0800 (PST) Reply-To: From: "Adina Simu \(asimu\)" To: "'Jonathan Rosenberg'" , Subject: RE: [midcom] STUN issue #7: recommended stateless server procedures Date: Tue, 19 Nov 2002 10:13:06 -0800 Message-ID: <001301c28ff7$4f6246d0$c1422acc@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.3416 In-Reply-To: <3DD9F79D.3090403@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 > The STUN specification doesn't give any specific algorithm > for doing a > stateless server. Stateless operation requires some way to hand out > usernames and passwords without storing them. > > Since it is easy to do this wrong, Steve Bellovin recommedned an > algorithm. The algorithm also allows for determination of the > source IP > address used for the TLS exchange, needed to handle another > one of the > open issues. His algorithm is: > > username = (sorry, I'm being very dense today) Why is rounded-time needed? Does this somehow imply reliable time? thanks -Adina > > where prefix is some string (I honestly don't know what this > is needed > for - I have a note in asking him), rounded-time is the time rounded > off, clientIP is the IP address where the TLS exchange came from, and > hmac is the hmac over the prefix, rounded-time and client IP, using a > server key. > > > password = > > This allows the server to verify the password against the username, > determine the staleness of the username, and determine the client IP > used in the TLS exchange, all without state. > > I recommend we document this algorithm in the spec. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > 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 Nov 19 13:52:26 2002 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 NAA12944 for ; Tue, 19 Nov 2002 13:52:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJIsbJ05687 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 13:54:37 -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 gAJIlwv05303; Tue, 19 Nov 2002 13:47:58 -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 gAJIh5v05069 for ; Tue, 19 Nov 2002 13:43:05 -0500 Received: from pmesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12490 for ; Tue, 19 Nov 2002 13:40:22 -0500 (EST) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0H5U0017L6MZ2Z@firewall.wcom.com> for midcom@ietf.org; Tue, 19 Nov 2002 18:42:36 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H5U004016LUC9@pmismtp03.wcomnet.com>; Tue, 19 Nov 2002 18:42:35 +0000 (GMT) Received: from ws041v4569 ([166.35.138.63]) by pmismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H5U004246MR5D@pmismtp03.wcomnet.com>; Tue, 19 Nov 2002 18:42:28 +0000 (GMT) Date: Tue, 19 Nov 2002 12:42:28 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] STUN issue #6: Client certs considered harmful In-reply-to: <200211191758.AAV86097@mira-sjc5-4.cisco.com> To: "'Melinda Shore'" Cc: "'Jonathan Rosenberg'" , midcom@ietf.org Message-id: <000401c28ffb$69dba200$3f8a23a6@ws041v4569> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-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 Unauthorized access/use of the server -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Tuesday, November 19, 2002 12:04 PM To: Christopher A. Martin Cc: 'Jonathan Rosenberg'; midcom@ietf.org Subject: Re: [midcom] STUN issue #6: Client certs considered harmful Could you describe what you'd be protecting against by having the client authenticated by the server? Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 13:55:16 2002 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 NAA12984 for ; Tue, 19 Nov 2002 13:55:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJIvSN05814 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 13:57: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 gAJIrnv05635; Tue, 19 Nov 2002 13:53:49 -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 gAJIn9v05438 for ; Tue, 19 Nov 2002 13:49:09 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12718 for ; Tue, 19 Nov 2002 13:46:26 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAJImtNf015769; Tue, 19 Nov 2002 10:48:55 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAV88294; Tue, 19 Nov 2002 10:44:18 -0800 (PST) Message-Id: <200211191844.AAV88294@mira-sjc5-4.cisco.com> To: "Christopher A. Martin" cc: "'Jonathan Rosenberg'" , midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] STUN issue #6: Client certs considered harmful In-Reply-To: Message from "Christopher A. Martin" of "Tue, 19 Nov 2002 12:42:28 CST." <000401c28ffb$69dba200$3f8a23a6@ws041v4569> Date: Tue, 19 Nov 2002 13:48:54 -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: , > Unauthorized access/use of the server Understood, but I think that the word "unauthorized" needs more explication in this context, or at least we need to understand what the risk to the server is. That's particularly a concern given that the mitigation (client authentication) introduces a DoS threat, itself. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 14:12:10 2002 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 OAA13618 for ; Tue, 19 Nov 2002 14:12:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJJEMG07311 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 14:14:22 -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 gAJJAnv07169; Tue, 19 Nov 2002 14:10:49 -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 gAJJ6gv06410 for ; Tue, 19 Nov 2002 14:06:42 -0500 Received: from pmesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13312 for ; Tue, 19 Nov 2002 14:03:59 -0500 (EST) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0H5U0042H7OD72@firewall.wcom.com> for midcom@ietf.org; Tue, 19 Nov 2002 19:05:02 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H5U00A017O5ZA@pmismtp02.wcomnet.com>; Tue, 19 Nov 2002 19:05:01 +0000 (GMT) Received: from ws041v4569 ([166.35.138.63]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H5U00A7A7O8D6@pmismtp02.wcomnet.com>; Tue, 19 Nov 2002 19:04:56 +0000 (GMT) Date: Tue, 19 Nov 2002 13:04:56 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] STUN issue #6: Client certs considered harmful In-reply-to: <200211191844.AAV88294@mira-sjc5-4.cisco.com> To: "'Melinda Shore'" Cc: "'Jonathan Rosenberg'" , midcom@ietf.org Message-id: <000f01c28ffe$8d2a9b00$3f8a23a6@ws041v4569> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-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 think that any service that provides a function such as this, to address NAT/firewalls traversal, has the potential to be abused. Authentication can reduce the number of connections at least by authenticating the subscribed users. Those that cannot authenticate can be dropped, reducing the application overhead that would be required to process unauthorized users. The digest mechansims for other protocols could probably be applied here as well as a minimal requirement to reduce overhead needed to perform authentication and prevent spoofing. If we are just saying, "hey, lets put a server up to permit everyone with a firewall, traversal capability, because we have plenty of system resources to handle it", then I would say, okeedokee, otherwise, might be a good idea, at least to address those folks that don't have the resources to give away to everyone, to follow up and confirm whether it is required or not. NOTE: This is just my kneejerk reaction to a single email that caught my eye, I am doing a bit of a diservice right now commenting without fully reading the entire thread or drafts to date, so ignore my comments while I go back and read up on the current status and drafts available. If it does sound like something that should be addressed I wanted to bring it up just in case someone who has been following lately can confirm whether this is a problem or not. Sorry, it s a resource issue, Chris -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Tuesday, November 19, 2002 12:49 PM To: Christopher A. Martin Cc: 'Jonathan Rosenberg'; midcom@ietf.org Subject: Re: [midcom] STUN issue #6: Client certs considered harmful > Unauthorized access/use of the server Understood, but I think that the word "unauthorized" needs more explication in this context, or at least we need to understand what the risk to the server is. That's particularly a concern given that the mitigation (client authentication) introduces a DoS threat, itself. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 15:15:46 2002 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 PAA15358 for ; Tue, 19 Nov 2002 15:15:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJKHwD11516 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 15:17:58 -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 gAJKBEv11084; Tue, 19 Nov 2002 15:11:14 -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 gAJK8xv10952 for ; Tue, 19 Nov 2002 15:08:59 -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 PAA15016 for ; Tue, 19 Nov 2002 15:06:15 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAJK8qY65738; Tue, 19 Nov 2002 21:08:52 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0, from userid 30) id 7B5FC799E1; Tue, 19 Nov 2002 21:07:37 +0100 (CET) Cc: "Louis-Nicolas Hamer" , "Kwok-Ho Chan" , "'Martin Stiemerling'" , midcom@ietf.org X-Accept-Language: de, en X-Priority: 3 (Normal) X-Mailer: SKYRiXgreen_3.1 NGMime_4.2.18 references: From: "Juergen Quittek" MIME-Version: 1.0 subject: RE: [midcom] Winnowing down the list To: "Cedric Aoun" content-type: text/plain; charset="iso-8859-1" date: Tue, 19 Nov 2002 21:07:37 +0100 content-transfer-encoding: 7bit Message-Id: <20021119200737.7B5FC799E1@imap.heidelberg.ccrle.nec.de> 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 Cedric, On the connection setup directionality: You argue that you anyway need to establish a security association, and you say you can use this step for telling the middlebox to ahich agent it should establish a MIDCOM session. This does not seem to be a flexible solution. 1. Your excluding manually installed keys at the middlebox. 2. You need to make sure, that the agent is up and running when you tell the middlebox about the keys and credentials of the particular agent. 3. You are requiring that each time the agent starts up, the security framework need to tell the middlebox about this. Particularly this point appears to be definitely too restrictive. I don't think we should run through installation of keys and credentials at the middlebox, each time a MIDCOM agent is started. A well configured system should be able to stop services (including the corresponding MIDCOM agents) and start them up again without running through the complete security management process again. On the COPS client types: The procedure you describe below is technically feasible. We agreed so far already in the discussion with Kwok. However, it is a hack rather than a clean solution. You first establish a COPS connection with one client type and then negotiate another client type dynamically, because COPS requires different client types for agents talking to the same middlebox. Then you open a second connection with the dynamically agreed client type. I'm asking me immediately: why is COPS asking you to do such strange things???? Maybe it's doing so for good reasons. If I read the COPS-PR RFC well, you are required to do so, because COPS is explicitly not intended for this kind of application (as MIDCOM protocol) where several agents are in competition for shared resources (bindings, IP addresses, port numbers). You circumvent this intention with your proposed procedure (that I call a hack). Juergen > Hi, > Here is a small memo on how COPS-PR manages the directionality and policy > rule contention (many Midcom agents manipulating the same policy rule). > In this memo, COPS = COPS-PR > > The first thing is to look at the applicability of off path Middle box > control, it applies to simple network topology where the Midcom agent has > awareness of the end points and the Middlebox connected to their network. > > Brief walk thru on establishing communications between the Midcom agent and > the Middlebox, and the directionality requirement > ------------------- > The MIDCOM agent and the Middlebox need to setup a trust relationship which > comprises of provisioning authorization policies on the Middlebox on which > Midcom agent is allowed to request MIDCOM policy rule installation. In > addition a security association is setup, in the case of COPS IPSEC ESP is > the preferred way, the MIDCOM agent sends the initial key management > protocol message (IKE or other). > Once the security association is up, the Middlebox establishes a TCP > connection with the Midcom agent, and send sends the COPS open message (I > won't go in much details in this note). When the Midcom agents requests a > policy rule installation, it will send an UNSOLLICITED COPS message etc ... > This behavior is compliant to the current COPS specification, as well as to > the requirement relevant to the establishment of communications between the > Middlebox and Midcom agent. > > Handling resource contention happening due to manipulation of policy rules > by several Midcom agents > ----- > In all protocol implementations, a resource coordination or management > function is required on the host to be able to handle resource contention. > The interaction between the COPS state machine and the resource management > function is quite simple, I didn't add it in this "brief" note, but could do > so in another separate mail if requested. > I have added some practicality in these walk thrus to show that this is real > and how is works with the current COPS specification, note that I tried to > keep it as simple as I can for readers not familiar with COPS. > The COPS PEP will establish a TCP connection (following the setup phase as > discussed above) to each MA, the PEP establishes a COPS "connection" to > each MA, each using a different Client-Type, in this case MIDCOM_1, > MIDCOM_2, MIDCOM_3. (Note that a single PEP can not have multiple COPS > connections with the same Client-Type (with the exception of NULL > Client-Type)). > Hence the PEP must use a different Client-Type for each MA. One method is > "Client-Type boot strapping". The PEP first performs a COPS OPEN with the > well know (standardized) Client-Type of MIDCOM, using this COPS connection > to indicate to the MA that it will follow up with a second COPS OPEN with a > specific none standardized Client-Type (MIDCOM_1). It is the second COPS > connection that will be used for the real MIDCOM communication. This is > very much like the way well known port numbers are used for the initial TCP > connection request, with the actual TCP traffic handled using a different > TCP port/process. > Notice the Client-Type range used for MIDCOM_1 is in the none reserved > range. And it is the MB that select the actual Client-Type to use. Hence > there will not be collision of the same Client-Type used on a single MB. > > Hope this helps clarifying on the resolution of the raised issues on the > list. > > In the sake of moving things forward on the protocol evaluation front, would > the WG think that proposing implementation guides on protocol x (x being one > of the remaining protocols in the list) being MIDCOM help in the selection > process? We need to address as well the authorization policy area and see > which protocol integrates best with authorization policy exchanges. > > Cheers > Cedric > > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: 12 November 2002 15:12 > To: Aoun, Cedric [GOLF:MA01:EXCH]; 'Martin Stiemerling'; Hamer, > Louis-Nicolas [CAR:AN22:EXCH] > Cc: midcom@ietf.org > Subject: RE: [midcom] Winnowing down the list > > > Cedric, > > -- Cedric Aoun wrote on 12 November 2002 11:18 +0100: > > > Martin, > > I believe that it is clearly stated in the protocol evaluation document > that > > several PDPs can access to the same resource by using an underlying > resource > > management function assisted with local policies. I think we have closed > on > > this > > one before the previous IETF meeting. > > I agree, we have closed this issue as far as the text in the evaluation > document is concerend. All protocols have several advantages and some > problems. However, the evaluation document does neither weight the problems, > nor does it give a recommendation concerning protocol selection. > > Therefore, we now have to enter the next stage. We have to weight the > advantages and disadvantages of the protocols in order to get closer to > a recommendation ot better: a protocol selection. And as far as I > understand Martin, he is not aiming at changing any line in the > evaluation, but at getting closer to a recommendation. > > One step in this direction is looking again at the disadvantages of the > candidate protocols, which are described in the evaluation document. > And then we have to find out for each of them, whether it is just a minor > disadvantage or a serious problem. > > > In the case you are discussing with Martin, I see at first glance technical > problem that can be solved, but I am not happy with using COPS-PR while > violating its specification in RFC 3084. > > RFC 3084 says: > > "There may be one or more PIBs for given area of policy and > different areas of policy may have different sets of PIBs." > (Section 1) > > So let's assume we have a Midcom PIB in the Midcom area. > > "Second, as it [COPS] has a single connection between the > policy client and server per area of policy control identified > by a COPS Client-Type, it guarantees only one server updates > a particular policy configuration at any given time. Such a > policy configuration is effectively locked, even from local > console configuration, while the PEP is connected to a PDP > via COPS." (Section 1.1) > > Conclusion: only a single Midcom agent would be allowed to request > or release middlebox resources. I know that technically we could just > ignore this and it works, but I do not feel comfortable when doing so. > > Support for doing so is given by > > "In order to support a model that includes multiple PDPs > controlling non-overlapping areas of policy on a single PEP, the > client-type specified by the PEP to the PDP is unique for the area > of policy being managed. A single client-type for a given area of > policy (e.g., QoS) will be used for all PIBs that exist in that > area. The client should treat all the COPS-PR client-types it > supports as non-overlapping and independent namespaces where > instances MUST NOT be shared." (Section 1) > > So maybe we can map agent identfiers to client types and use a lot of > existing COPS functonality. But still it leaves the impression of a > hack rather than of a solution. > > Juergen > > > > Cedric > > > > > > -----Original Message----- > > From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] > > Sent: 12 November 2002 11:03 > > To: Hamer, Louis-Nicolas [CAR:AN22:EXCH] > > Cc: midcom@ietf.org > > Subject: Re: [midcom] Winnowing down the list > > > > > > > > Louis-Nicolas Hamer wrote: > > > >> Melinda, all, > >> > > [....] > > > > > >> > >> The only reason invoked against COPS was the directionality requirement. > >> Kwok explained in great lengths how this was not a big deal - it can be > >> fixed quite easily. So I object to your proposal to remove COPS. > > > > > > Hmm, there is another reason against COPS: > > The COPS PEP is not able to receive configuration data from multiple PDP > > for the *same* resource, e.g. the middlebox can not receive policy rule > > configuration requests from different agents for the same packet filter > > at the same time. > > > > Martin > > > > > >> > >> As I have indicated before, I think COPS, SNMP and MEGACO are very good > >> fits for MIDCOM. > >> I would suggest that the best way forward would be to see what the WG > >> decides on the approach to take to > >> "pinpoint" the best protocol to use - I believe you have > >> that point on the agenda for the Atlanta meeting, right? > >> > >> l-n > >> > >> > >> > -----Original Message----- > >> > From: Melinda Shore [mailto:mshore@cisco.com] > >> > Sent: Friday, November 08, 2002 4:51 PM > >> > To: midcom@ietf.org > >> > Subject: [midcom] Winnowing down the list > >> > > >> > > >> > I'd like to continue to try to narrow the list of midcom > >> > candidates. From the discussion so far it looks like a lot > >> > of people are dubious about COPS, so here's the question: > >> > > >> > Is there any objection to removing COPS from the list of > >> > candidate midcom protocols? If you object, please give a reason. > >> > > >> > 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 > > > -- fier! _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 15:21:25 2002 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 PAA15544 for ; Tue, 19 Nov 2002 15:21:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJKNcw11779 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 15:23: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 gAJKH5v11459; Tue, 19 Nov 2002 15:17: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 gAJKEfv11310 for ; Tue, 19 Nov 2002 15:14:41 -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 PAA15236 for ; Tue, 19 Nov 2002 15:11:58 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.47]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAJKEaYH003281; Tue, 19 Nov 2002 15:14:37 -0500 (EST) Message-ID: <3DDA9BA9.1050900@dynamicsoft.com> Date: Tue, 19 Nov 2002 15:14: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: "Christopher A. Martin" CC: "'Melinda Shore'" , midcom@ietf.org Subject: Re: [midcom] STUN issue #6: Client certs considered harmful References: <000f01c28ffe$8d2a9b00$3f8a23a6@ws041v4569> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit inline. Christopher A. Martin wrote: > I think that any service that provides a function such as this, Function? The STUN server is providing a reflector service. The activity of authenticating the client for purposes of authorization to use the service exceeds the work in actually providing the service. Authorization is only needed to manage access and usage to constrained resources. That is not the case here. It has been the operating procedure for a LONG time that there is absolutely no requirement for client authentication or authorization. If you are proposing to change that assumption, please provide some concrete reasoning. > to > address NAT/firewalls traversal, has the potential to be abused. > Authentication can reduce the number of connections at least by > authenticating the subscribed users. Those that cannot authenticate can > be dropped, reducing the application overhead that would be required to > process unauthorized users. The digest mechansims for other protocols > could probably be applied here as well as a minimal requirement to > reduce overhead needed to perform authentication and prevent spoofing. See above. > > If we are just saying, "hey, lets put a server up to permit everyone > with a firewall, traversal capability, because we have plenty of system > resources to handle it", then I would say, okeedokee, otherwise, might > be a good idea, at least to address those folks that don't have the > resources to give away to everyone, to follow up and confirm whether it > is required or not. What resources??? This is a packet reflector. > > NOTE: > This is just my kneejerk reaction to a single email that caught my eye, > I am doing a bit of a diservice right now commenting without fully > reading the entire thread or drafts to date, so ignore my comments while > I go back and read up on the current status and drafts available. Disservice indeed. I would strongly recommend reading the documents before criticizing the design choices that have been made. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 15:51:31 2002 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 PAA16260 for ; Tue, 19 Nov 2002 15:51:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJKriE13572 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 15:53:44 -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 gAJKl7v13318; Tue, 19 Nov 2002 15:47: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 gAJKitv13232 for ; Tue, 19 Nov 2002 15:44:55 -0500 Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16057 for ; Tue, 19 Nov 2002 15:42:11 -0500 (EST) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0H5U00KDIC7GLM@firewall.wcom.com> for midcom@ietf.org; Tue, 19 Nov 2002 20:42:53 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H5U00001C1FKJ@pmismtp04.wcomnet.com>; Tue, 19 Nov 2002 20:42:52 +0000 (GMT) Received: from ws041v4569 ([166.35.138.63]) by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H5U00077C4NDH@pmismtp04.wcomnet.com>; Tue, 19 Nov 2002 20:41:11 +0000 (GMT) Date: Tue, 19 Nov 2002 14:41:11 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] STUN issue #6: Client certs considered harmful In-reply-to: <3DDA9BA9.1050900@dynamicsoft.com> To: "'Jonathan Rosenberg'" Cc: "'Melinda Shore'" , midcom@ietf.org Message-id: <003b01c2900b$ff23ee20$3f8a23a6@ws041v4569> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-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 ok -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, November 19, 2002 2:15 PM To: Christopher A. Martin Cc: 'Melinda Shore'; midcom@ietf.org Subject: Re: [midcom] STUN issue #6: Client certs considered harmful inline. Christopher A. Martin wrote: > I think that any service that provides a function such as this, Function? The STUN server is providing a reflector service. The activity of authenticating the client for purposes of authorization to use the service exceeds the work in actually providing the service. Authorization is only needed to manage access and usage to constrained resources. That is not the case here. It has been the operating procedure for a LONG time that there is absolutely no requirement for client authentication or authorization. If you are proposing to change that assumption, please provide some concrete reasoning. > to > address NAT/firewalls traversal, has the potential to be abused. > Authentication can reduce the number of connections at least by > authenticating the subscribed users. Those that cannot authenticate > can be dropped, reducing the application overhead that would be > required to process unauthorized users. The digest mechansims for > other protocols could probably be applied here as well as a minimal > requirement to reduce overhead needed to perform authentication and > prevent spoofing. See above. > > If we are just saying, "hey, lets put a server up to permit everyone > with a firewall, traversal capability, because we have plenty of > system resources to handle it", then I would say, okeedokee, > otherwise, might be a good idea, at least to address those folks that > don't have the resources to give away to everyone, to follow up and > confirm whether it is required or not. What resources??? This is a packet reflector. > > NOTE: > This is just my kneejerk reaction to a single email that caught my > eye, I am doing a bit of a diservice right now commenting without > fully reading the entire thread or drafts to date, so ignore my > comments while I go back and read up on the current status and drafts > available. Disservice indeed. I would strongly recommend reading the documents before criticizing the design choices that have been made. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 16:54:52 2002 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 QAA18069 for ; Tue, 19 Nov 2002 16:54:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJLv6f17604 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 16:57: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 gAJLrav17435; Tue, 19 Nov 2002 16:53:37 -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 gAJLkZv17191 for ; Tue, 19 Nov 2002 16:46:35 -0500 Received: from dnsmx1pya.telcordia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17704 for ; Tue, 19 Nov 2002 16:43:47 -0500 (EST) Received: from notes800.cc.telcordia.com (notes800a.cc.telcordia.com [128.96.79.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id QAA21583; Tue, 19 Nov 2002 16:46:04 -0500 (EST) Subject: Re: [midcom] STUN issue #5: reflector attacks To: Jonathan Rosenberg Cc: midcom@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Panayiotis A. Thermos" Date: Tue, 19 Nov 2002 16:49:05 -0500 X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at 11/19/2002 04:46:05 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Just for clarification purposes could you provide an example of such attack? One scenario that I can think is where a malicious user generates multiple STUN messages with the RESPONSE-ADDRESS attribute pointing to a "victim" host then according to the current draft (and depending on the implementation) the victim host will check the MESSAGE-INTEGRITY field and it will be ignored since it is not a message that the victim host has generated. I'm not clear in what scenario the REFLECTED-FROM will be most effective given that we already some infotmation from previous interaction over SSL. There is also the case where a legitimate STUN response has to be be send to another "trusted" multimedia component (other than the one that generated the request), which is part of the end-user's environment. This should be addressed seperately. Thanks for your help. Jonathan Rosenberg To: midcom@ietf.org Subject: [midcom] STUN issue #5: reflector attacks 11/19/2002 03:22 AM STUN has a RESPONSE-ADDRESS attribute. This attribute is used by the client to tell the server the IP/port where to send the response. This can be used by an attacker as a reflector attack, to mask the true source IP address of a dos attack. Steve Bellovin suggested that this is best dealt with by adding, to the response, the source IP where the request came from, and to make sure its integrity protected. This adds traceability. So, you can't prevent this, but you can see the true source address. The proposal is to accept his recommendation and add a REFLECTED-FROM attribute containing this source address. Note that this source address can't actually be the one from the UDP request (since thats easily spoofed). But rather, from the TLS exchange that established the USERNAME used in the request. That requires state in the server, OR a smart implementation which creates usernames that contain this IP, along with an hmac over them to protect it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org 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 Nov 19 17:36:53 2002 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 RAA19271 for ; Tue, 19 Nov 2002 17:36:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJMd8121344 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 17:39:08 -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 gAJMZev20548; Tue, 19 Nov 2002 17:35:40 -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 gAI7Odv06665 for ; Mon, 18 Nov 2002 02:24:39 -0500 Received: from mta0 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14727 for ; Mon, 18 Nov 2002 02:21:50 -0500 (EST) Received: from ford (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0H5R006JIGHYYX@mta0.huawei.com> for midcom@ietf.org; Mon, 18 Nov 2002 15:22:47 +0800 (CST) Date: Mon, 18 Nov 2002 15:25:10 +0800 From: cheng zhengqun To: midcom@ietf.org Message-id: <000001c28ed3$a10ca7c0$ce064d0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_diXqW1XKIuOX+RgEE1yBKQ)" Importance: High X-Priority: 1 (Highest) X-MSMail-priority: High Subject: [midcom] Consultation Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_diXqW1XKIuOX+RgEE1yBKQ) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear All: Until now, there is no famous port for MIDCOM request, That is, what=92s the default port for MIDCOM request, It would be=20 Very kind for anyone to give me some suggestion? =20 Best regards! Yours: Cheng Zhengqun --Boundary_(ID_diXqW1XKIuOX+RgEE1yBKQ) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT

Dear All:

Until now, there is no famous port for MIDCOM request,

That is, what’s the default port for MIDCOM request, It would be

Very kind for anyone to give me some suggestion?

 

Best regards!

                     Yours: Cheng Zhengqun

--Boundary_(ID_diXqW1XKIuOX+RgEE1yBKQ)-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 18:24:59 2002 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 SAA20546 for ; Tue, 19 Nov 2002 18:24:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJNREl23674 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 18:27:14 -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 gAJNNlv23588; Tue, 19 Nov 2002 18:23:47 -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 gAJNJav23427 for ; Tue, 19 Nov 2002 18:19:36 -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 SAA20394 for ; Tue, 19 Nov 2002 18:16:50 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAJNJSY68064; Wed, 20 Nov 2002 00:19:28 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de ([204.42.66.68]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id gAJNJPkh035660; Tue, 19 Nov 2002 23:19:26 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) Message-ID: <3DDAC6F8.4030603@ccrle.nec.de> Date: Wed, 20 Nov 2002 00:19:20 +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: cheng zhengqun CC: midcom@ietf.org Subject: Re: [midcom] Consultation References: <000001c28ed3$a10ca7c0$ce064d0a@huawei.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 Hi cheng zhengqun, Until now there is even no elected MIDCOM protocol! This implies that there is no transport protocol port as well. Cheers Martin > Dear All: > > Until now, there is no famous port for MIDCOM request, > > That is, what?s the default port for MIDCOM request, It would be > > Very kind for anyone to give me some suggestion? > > > > Best regards! > > Yours: Cheng Zhengqun > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 18:25:12 2002 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 SAA20570 for ; Tue, 19 Nov 2002 18:25:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJNRRG23687 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 18:27:27 -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 gAJNKrv23480; Tue, 19 Nov 2002 18:20:53 -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 gAJNHQv23355 for ; Tue, 19 Nov 2002 18:17:26 -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 SAA20354 for ; Tue, 19 Nov 2002 18:14:39 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAJNHIY68040 for ; Wed, 20 Nov 2002 00:17:18 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de ([204.42.66.68]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id gAJNHHkh035657 for ; Tue, 19 Nov 2002 23:17:18 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) Message-ID: <3DDAC663.8050801@ccrle.nec.de> Date: Wed, 20 Nov 2002 00:16: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] Semantics slides of MIDOM session at 55th IETF 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, please find at this url the semantics slides that have been presented at the 55th IETF meeting in Atlanta. http://www2.fh-koeln.de/~mstiemerling/ietf55_midcom_semantics.ppt Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 19:03:42 2002 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 TAA21139 for ; Tue, 19 Nov 2002 19:03:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK05ww25303 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 19:05:58 -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 gAJNxLv25105; Tue, 19 Nov 2002 18:59: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 gAJNtYv25013 for ; Tue, 19 Nov 2002 18:55:34 -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 SAA20962 for ; Tue, 19 Nov 2002 18:52:47 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAJNtQY68471 for ; Wed, 20 Nov 2002 00:55:26 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de ([204.42.66.197]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id gAJNtPkh035796 for ; Tue, 19 Nov 2002 23:55:26 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) Message-ID: <3DDACF3E.2010009@ccrle.nec.de> Date: Wed, 20 Nov 2002 00:54:38 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE 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] Semantics issues 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, since the presentation time at the IETF meeting was to short I'll send all discussion issues to the mailling list in separate emails. Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 19:06:56 2002 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 TAA21238 for ; Tue, 19 Nov 2002 19:06:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK09Bf26037 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 19:09:11 -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 gAK02ev25221; Tue, 19 Nov 2002 19:02:40 -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 gAJNtev25020 for ; Tue, 19 Nov 2002 18:55:40 -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 SAA20978 for ; Tue, 19 Nov 2002 18:52:53 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAJNtWY68475 for ; Wed, 20 Nov 2002 00:55:32 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de ([204.42.66.197]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id gAJNtVkh035799 for ; Tue, 19 Nov 2002 23:55:32 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) Message-ID: <3DDACF44.4010800@ccrle.nec.de> Date: Wed, 20 Nov 2002 00:54:44 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE 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] Semantics #1: PRR behaviour 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 semantics propose currently that PRR does - outside address/port allocation for a traditional NAT - outside and inside address/port allocation for a twice NAT. But it is really needed to allocate both sides of a twice NAT during a PRR transaction or is it sufficient enough to just allocate the outside address/port? The semantics could be simplified if only the outside address/port is allocated (indepent of middlebox type). Or do you see a scenario where both sides must be allocated during the PRR transaction? _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 19:07:02 2002 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 TAA21253 for ; Tue, 19 Nov 2002 19:07:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK09IB26058 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 19:09:18 -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 gAK05sv25296; Tue, 19 Nov 2002 19:05: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 gAJNthv25024 for ; Tue, 19 Nov 2002 18:55:43 -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 SAA20981 for ; Tue, 19 Nov 2002 18:52:56 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAJNtZY68479 for ; Wed, 20 Nov 2002 00:55:35 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de ([204.42.66.197]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id gAJNtYkh035802 for ; Tue, 19 Nov 2002 23:55:35 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) Message-ID: <3DDACF47.4050103@ccrle.nec.de> Date: Wed, 20 Nov 2002 00:54:47 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE 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] Semantics#2: Group transactions 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 - Currently: Groups are created explicitly - New proposal: Groups are created implicitly by PRR or PER transaction - Impact on group transaction - GE and AGD can be dropped - GLC, GL and GS are kept - Default group can be dropped - No group liftime - Group state machine can be dropped The whole group control can be simplified with dropping the explicity group establishment, so that groups are established during a PRR or PER transaction. The GLC transaction would than delete all policy rules belonging to the group when the lifetime is set to zero or change the lifetime of each policy rule (lifetime > 0) _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 19:12:15 2002 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 TAA21382 for ; Tue, 19 Nov 2002 19:12:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK0EUg26250 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 19:14:30 -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 gAK07xv25957; Tue, 19 Nov 2002 19:07:59 -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 gAJNxlv25121 for ; Tue, 19 Nov 2002 18:59:47 -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 SAA21060 for ; Tue, 19 Nov 2002 18:57:00 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAJNxdY68533 for ; Wed, 20 Nov 2002 00:59:39 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de ([204.42.66.197]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id gAJNxckh035809 for ; Tue, 19 Nov 2002 23:59:39 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) Message-ID: <3DDAD031.3000004@ccrle.nec.de> Date: Wed, 20 Nov 2002 00:58:41 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE 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] Semantics#3: Wildcarding 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 Wildcarding is, due to several middlebox types and protocol types, a very tough topic. However, I'll but some thoughts on the list later. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 19:15:15 2002 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 TAA21439 for ; Tue, 19 Nov 2002 19:15:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK0HU126360 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 19:17:30 -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 gAK0E7v26238; Tue, 19 Nov 2002 19:14: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 gAK09Gv26054 for ; Tue, 19 Nov 2002 19:09:16 -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 TAA21213 for ; Tue, 19 Nov 2002 19:06:29 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAK098Y68668 for ; Wed, 20 Nov 2002 01:09:08 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de ([204.42.66.197]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id gAK096kh035865 for ; Wed, 20 Nov 2002 00:09:07 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) Message-ID: <3DDAD253.1090905@ccrle.nec.de> Date: Wed, 20 Nov 2002 01:07:47 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE 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] Semantics #5: Split PER transaction 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 Currently the state transitions in the policy rule state machine from - PRID UNUSED to ENABLED - RESERVED to ENABLED 'using' the same PER transaction. If you take a look into the semantics draft you will recognize that the PER for the RESERVED to ENABLED transition doesn't need all the parameters as the PER for UNUSED to ENABLED does need. So it would make sense to separate them both into two different transactions: PER1 for RESERVED to ENABLED PER2 for PRID UNUSED to ENABLED (The names PER1 and PER2 are just for the first clarification!) This would significantly simplify the semantics for the PER transaction. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 19:16:21 2002 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 TAA21464 for ; Tue, 19 Nov 2002 19:16:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK0Ibk26417 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 19:18:37 -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 gAK0C6v26147; Tue, 19 Nov 2002 19:12: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 gAK09Cv26049 for ; Tue, 19 Nov 2002 19:09:12 -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 TAA21209 for ; Tue, 19 Nov 2002 19:06:25 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAK094Y68664 for ; Wed, 20 Nov 2002 01:09:04 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de ([204.42.66.197]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id gAK093kh035862 for ; Wed, 20 Nov 2002 00:09:03 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) Message-ID: <3DDAD24F.3010001@ccrle.nec.de> Date: Wed, 20 Nov 2002 01:07:43 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE 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] Semantics #4: Return values in 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 What to return in PER transaction reply if inside and/or outside address/port are not allocated? Examples: middlebox is packet filter (no inside or outside address/port) or traditional NAT (only outside address/port). First choice: Return emtpy/none marker. This has the impact that the middlebox type is no longer transparent to the agent, i.e. the agent has to care what type of middlebox it is using Second choice: Return external and/or internal endpoint addresses/port if appropriate. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 19:20:04 2002 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 TAA21572 for ; Tue, 19 Nov 2002 19:20:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK0MKh26638 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 19:22:20 -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 gAK0Iuv26434; Tue, 19 Nov 2002 19:18:56 -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 gAK0D6v26191 for ; Tue, 19 Nov 2002 19:13:06 -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 TAA21341 for ; Tue, 19 Nov 2002 19:10:19 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAK0CwY68709 for ; Wed, 20 Nov 2002 01:12:58 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de ([204.42.66.197]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id gAK0Cukh035886 for ; Wed, 20 Nov 2002 00:12:57 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) Message-ID: <3DDAD32F.1090103@ccrle.nec.de> Date: Wed, 20 Nov 2002 01:11:27 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE 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] Semantics #6: Message Queuing 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 Is it required to add a 'first come first serve' message processing statement into section 2.1.2 "Atomicity" or is the text about 'atomic operation' sufficient enough? _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 19:21:11 2002 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 TAA21636 for ; Tue, 19 Nov 2002 19:21:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK0NQn26716 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 19:23: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 gAK0Gsv26336; Tue, 19 Nov 2002 19:16: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 gAK0ANv26119 for ; Tue, 19 Nov 2002 19:10:23 -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 TAA21272 for ; Tue, 19 Nov 2002 19:07:35 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAK0AEY68684 for ; Wed, 20 Nov 2002 01:10:14 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de ([204.42.66.197]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id gAK0ADkh035883 for ; Wed, 20 Nov 2002 00:10:13 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) Message-ID: <3DDAD293.3030807@ccrle.nec.de> Date: Wed, 20 Nov 2002 01:08:51 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE 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] Semantics #5: Split PER transaction 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 Currently the state transitions in the policy rule state machine from - PRID UNUSED to ENABLED - RESERVED to ENABLED 'using' the same PER transaction. If you take a look into the semantics draft you will recognize that the PER for the RESERVED to ENABLED transition doesn't need all the parameters as the PER for UNUSED to ENABLED does need. So it would make sense to separate them both into two different transactions: PER1 for RESERVED to ENABLED PER2 for PRID UNUSED to ENABLED (The names PER1 and PER2 are just for the first clarification!) This would significantly simplify the semantics for the PER transaction. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 19:22:08 2002 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 TAA21663 for ; Tue, 19 Nov 2002 19:22:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK0OOW26755 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 19:24: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 gAK0L0v26541; Tue, 19 Nov 2002 19:21:00 -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 gAK0DBv26198 for ; Tue, 19 Nov 2002 19: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 TAA21345 for ; Tue, 19 Nov 2002 19:10:24 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAK0D4Y68722 for ; Wed, 20 Nov 2002 01:13:04 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de ([204.42.66.197]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id gAK0D2kh035889 for ; Wed, 20 Nov 2002 00:13:03 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) Message-ID: <3DDAD336.9040703@ccrle.nec.de> Date: Wed, 20 Nov 2002 01:11:34 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE 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] Semantics #5: Split PER transaction 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 Currently the state transitions in the policy rule state machine from - PRID UNUSED to ENABLED - RESERVED to ENABLED 'using' the same PER transaction. If you take a look into the semantics draft you will recognize that the PER for the RESERVED to ENABLED transition doesn't need all the parameters as the PER for UNUSED to ENABLED does need. So it would make sense to separate them both into two different transactions: PER1 for RESERVED to ENABLED PER2 for PRID UNUSED to ENABLED (The names PER1 and PER2 are just for the first clarification!) This would significantly simplify the semantics for the PER transaction. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 19:27:27 2002 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 TAA21782 for ; Tue, 19 Nov 2002 19:27:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK0TfW27082 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 19:29: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 gAK0N4v26672; Tue, 19 Nov 2002 19:23: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 gAK0KPv26520 for ; Tue, 19 Nov 2002 19:20:25 -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 TAA21510 for ; Tue, 19 Nov 2002 19:17:38 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAK0KHY68815 for ; Wed, 20 Nov 2002 01:20:17 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de ([204.42.66.197]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id gAK0KCkh035926 for ; Wed, 20 Nov 2002 00:20:16 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) Message-ID: <3DDAD4D3.3000308@ccrle.nec.de> Date: Wed, 20 Nov 2002 01:18:27 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE 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] Semantics #8: Other open issues 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 Here is a list of minor issues: - Separate IP protocol version and transport protocol type in PRR/PER transaction? Currently these are defined: IP4/IP6/UDP4/UDP6/TCP4/TCP6 - Need to support ICMP, IGMP, RSVP,... as protocol types? - Encryption method in SE transaction. Should SE failure reply convey supported encryption methods? Curently a 'don't understand your encryption' is returned. - The security considerations need some further elaboration - Any other issues??? _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 19 19:29:28 2002 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 TAA21807 for ; Tue, 19 Nov 2002 19:29:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK0VgJ27182 for midcom-archive@odin.ietf.org; Tue, 19 Nov 2002 19:31:42 -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 gAK0PAv26807; Tue, 19 Nov 2002 19:25:10 -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 gAK0GUv26322 for ; Tue, 19 Nov 2002 19:16:30 -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 TAA21414 for ; Tue, 19 Nov 2002 19:13:43 -0500 (EST) Received: from ftp.ccrle.nec.de (ftp.ccrle.nec.de [195.37.70.21]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAK0GMY68769 for ; Wed, 20 Nov 2002 01:16:22 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de ([204.42.66.197]) (authenticated bits=0) by ftp.ccrle.nec.de (8.12.6/8.12.3) with ESMTP id gAK0GLkh035907 for ; Wed, 20 Nov 2002 00:16:22 GMT (envelope-from Martin.Stiemerling@ccrle.nec.de) Message-ID: <3DDAD3F5.2080707@ccrle.nec.de> Date: Wed, 20 Nov 2002 01:14:45 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE 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] Semantics #7: Capability exchange on Session Establishment 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 Currently the semantics document proposes these capabilitiy information: - Type of middlebox - IP address wildcard support - Port wildcard support - supported IP versions - supported optional transactions - policy rule persistency - maximum policy rule lifetime - name of the default group Do you see any other capabilities that should be announced? _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Nov 20 10:18:22 2002 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 KAA21436 for ; Wed, 20 Nov 2002 10:18:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAKFKXo21170 for midcom-archive@odin.ietf.org; Wed, 20 Nov 2002 10:20:33 -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 gAKFDVv20856; Wed, 20 Nov 2002 10:13:32 -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 gAKFAvv20678 for ; Wed, 20 Nov 2002 10:10:57 -0500 Received: from dnsmx1pya.telcordia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21213 for ; Wed, 20 Nov 2002 10:07:56 -0500 (EST) Received: from notes800.cc.telcordia.com (notes800a.cc.telcordia.com [128.96.79.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id KAA26082; Wed, 20 Nov 2002 10:09:42 -0500 (EST) Subject: Re: [midcom] STUN issue #7: recommended stateless server procedures To: Jonathan Rosenberg Cc: midcom@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Panayiotis A. Thermos" Date: Wed, 20 Nov 2002 10:12:47 -0500 X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at 11/20/2002 10:09:43 AM 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: , I assume that the prefix would be a random string of length 12 characters or more to strengthen the "username" value. Peter Jonathan Rosenberg To: midcom@ietf.org Subject: [midcom] STUN issue #7: recommended stateless server procedures 11/19/2002 03:34 AM The STUN specification doesn't give any specific algorithm for doing a stateless server. Stateless operation requires some way to hand out usernames and passwords without storing them. Since it is easy to do this wrong, Steve Bellovin recommedned an algorithm. The algorithm also allows for determination of the source IP address used for the TLS exchange, needed to handle another one of the open issues. His algorithm is: username = where prefix is some string (I honestly don't know what this is needed for - I have a note in asking him), rounded-time is the time rounded off, clientIP is the IP address where the TLS exchange came from, and hmac is the hmac over the prefix, rounded-time and client IP, using a server key. password = This allows the server to verify the password against the username, determine the staleness of the username, and determine the client IP used in the TLS exchange, all without state. I recommend we document this algorithm in the spec. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org 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 Nov 20 10:35:57 2002 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 KAA22156 for ; Wed, 20 Nov 2002 10:35:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAKFc8s22842 for midcom-archive@odin.ietf.org; Wed, 20 Nov 2002 10:38:08 -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 gAKFVWv21768; Wed, 20 Nov 2002 10:31:32 -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 gAKFPYv21420 for ; Wed, 20 Nov 2002 10:25:34 -0500 Received: from dnsmx1pya.telcordia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21574 for ; Wed, 20 Nov 2002 10:22:52 -0500 (EST) Received: from notes800.cc.telcordia.com (notes800a.cc.telcordia.com [128.96.79.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id KAA02616; Wed, 20 Nov 2002 10:24:42 -0500 (EST) Subject: Re: [midcom] STUN issue #6: Client certs considered harmful To: Melinda Shore Cc: "Christopher A. Martin" , "'Jonathan Rosenberg'" , midcom@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Panayiotis A. Thermos" Date: Wed, 20 Nov 2002 10:27:48 -0500 X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at 11/20/2002 10:24:43 AM 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: , I believe the initial inception of STUN was to work similar to a "ping" request. Adding additional authentication mechanisms to the client side will add more processing that is intended. I wouldn't want to authenticate each time I'm "pinging" a host. If you want to limit who is accessing the STUN service you can enforce filtering rules in your filtering device (e.g. router/firewall) or even integrate an IP lookup feature in your STUN server implementation (similar to TCP wrappers). Once you start requiring client authentication it means that you have to maintain a user/password database or a directory with user credentials (e.g. certificates). Just a thought. Melinda Shore cc: "'Jonathan Rosenberg'" , 11/19/2002 midcom@ietf.org, (bcc: Panayiotis A. Thermos/Telcordia) 01:48 PM Subject: Re: [midcom] STUN issue #6: Client certs considered harmful > Unauthorized access/use of the server Understood, but I think that the word "unauthorized" needs more explication in this context, or at least we need to understand what the risk to the server is. That's particularly a concern given that the mitigation (client authentication) introduces a DoS threat, itself. 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 Nov 20 10:58:42 2002 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 KAA22991 for ; Wed, 20 Nov 2002 10:58:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAKG0rc24328 for midcom-archive@odin.ietf.org; Wed, 20 Nov 2002 11:00: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 gAKFvLv24022; Wed, 20 Nov 2002 10:57: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 gAKFskv23895 for ; Wed, 20 Nov 2002 10:54:46 -0500 Received: from pmesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22761 for ; Wed, 20 Nov 2002 10:52:02 -0500 (EST) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0H5V00MJDTJ5DD@firewall.wcom.com> for midcom@ietf.org; Wed, 20 Nov 2002 15:54:41 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H5V00A01TIPJY@pmismtp04.wcomnet.com>; Wed, 20 Nov 2002 15:54:38 +0000 (GMT) Received: from ws041v4569 ([166.50.113.192]) by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H5V00A4WTHK9M@pmismtp04.wcomnet.com>; Wed, 20 Nov 2002 15:53:45 +0000 (GMT) Date: Wed, 20 Nov 2002 09:53:44 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] STUN issue #6: Client certs considered harmful In-reply-to: To: "'Panayiotis A. Thermos'" , "'Melinda Shore'" Cc: "'Jonathan Rosenberg'" , midcom@ietf.org Message-id: <002f01c290ad$0201a780$9a00a8c0@ws041v4569> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-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 understand. It is just my personal opinion that the concept of this type of ping could be considered a violation of many security policies in place that could be abused by users behind networks not intended to use it. Then again, it could be blocked by policies at the security enforcement point. I don't believe it to be simply a "ping" tool, it provides information to internal users in order to provide traversal/circumvention that may not be authorized. But if this is the intention of STUN then that is fine, as long as I have presented the concern that I have, everyone can make their own opinion. This will be my last comment on this topic, I don't want to waste cycles of everyone here toward the current goals and direction of MIDCOM. It has its place, for SOHO and individuals this is perfect, for enterprise this may not fit. So use the right tool for he right job, eh, as long as it can be prevented for the enterprise? Thanks, Chris -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Panayiotis A. Thermos Sent: Wednesday, November 20, 2002 9:28 AM To: Melinda Shore Cc: Christopher A. Martin; 'Jonathan Rosenberg'; midcom@ietf.org Subject: Re: [midcom] STUN issue #6: Client certs considered harmful I believe the initial inception of STUN was to work similar to a "ping" request. Adding additional authentication mechanisms to the client side will add more processing that is intended. I wouldn't want to authenticate each time I'm "pinging" a host. If you want to limit who is accessing the STUN service you can enforce filtering rules in your filtering device (e.g. router/firewall) or even integrate an IP lookup feature in your STUN server implementation (similar to TCP wrappers). Once you start requiring client authentication it means that you have to maintain a user/password database or a directory with user credentials (e.g. certificates). Just a thought. Melinda Shore cc: "'Jonathan Rosenberg'" , 11/19/2002 midcom@ietf.org, (bcc: Panayiotis A. Thermos/Telcordia) 01:48 PM Subject: Re: [midcom] STUN issue #6: Client certs considered harmful > Unauthorized access/use of the server Understood, but I think that the word "unauthorized" needs more explication in this context, or at least we need to understand what the risk to the server is. That's particularly a concern given that the mitigation (client authentication) introduces a DoS threat, itself. 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 Nov 21 03:30:07 2002 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 DAA25308 for ; Thu, 21 Nov 2002 03:30:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAL8WQk29794 for midcom-archive@odin.ietf.org; Thu, 21 Nov 2002 03:32: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 gAL8PHv29444; Thu, 21 Nov 2002 03:25: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 gAL8Kgv29286 for ; Thu, 21 Nov 2002 03:20: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 DAA25234 for ; Thu, 21 Nov 2002 03:17:52 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.58]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAL8KQYH005537; Thu, 21 Nov 2002 03:20:27 -0500 (EST) Message-ID: <3DDC9748.4050709@dynamicsoft.com> Date: Thu, 21 Nov 2002 03:20:24 -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: "Panayiotis A. Thermos" CC: midcom@ietf.org Subject: Re: [midcom] STUN issue #5: reflector attacks 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 It was my understanding that he was referring to this: V. Paxson, "An analysis of using reflectors for distributed denial of service attacks," ACM Computer Communication Review , Vol. 31, July 2001. -Jonathan R. Panayiotis A. Thermos wrote: > Just for clarification purposes could you provide an example of such > attack? > > One scenario that I can think is where a malicious user generates multiple > STUN messages with the RESPONSE-ADDRESS attribute pointing to > a "victim" host then according to the current draft (and depending on the > implementation) the victim host will check the MESSAGE-INTEGRITY > field and it will be ignored since it is not a message that the victim > host > has generated. I'm not clear in what scenario the REFLECTED-FROM > will be most effective given that we already some infotmation from > previous interaction over SSL. > > There is also the case where a legitimate STUN response has to be > be send to another "trusted" multimedia component (other than the one > that generated the request), which is part of the end-user's environment. > This should be addressed seperately. > > Thanks for your help. > > > > > Jonathan > Rosenberg To: midcom@ietf.org > csoft.com> Subject: [midcom] STUN issue #5: reflector attacks > > 11/19/2002 > 03:22 AM > > > > > > > > STUN has a RESPONSE-ADDRESS attribute. This attribute is used by the > client to tell the server the IP/port where to send the response. This > can be used by an attacker as a reflector attack, to mask the true > source IP address of a dos attack. > > Steve Bellovin suggested that this is best dealt with by adding, to the > response, the source IP where the request came from, and to make sure > its integrity protected. This adds traceability. So, you can't prevent > this, but you can see the true source address. The proposal is to accept > his recommendation and add a REFLECTED-FROM attribute containing this > source address. > > Note that this source address can't actually be the one from the UDP > request (since thats easily spoofed). But rather, from the TLS exchange > that established the USERNAME used in the request. That requires state > in the server, OR a smart implementation which creates usernames that > contain this IP, along with an hmac over them to protect it. > > > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > 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 Thu Nov 21 03:38:21 2002 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 DAA25494 for ; Thu, 21 Nov 2002 03:38:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAL8efp30733 for midcom-archive@odin.ietf.org; Thu, 21 Nov 2002 03:40: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 gAL8bBv30155; Thu, 21 Nov 2002 03:37:11 -0500 Received: from ietf.org ([132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAL8Uvv29725 for ; Thu, 21 Nov 2002 03:31:57 -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 DAA25266 for ; Thu, 21 Nov 2002 03:27:25 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.58]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAL8U5YH005541; Thu, 21 Nov 2002 03:30:06 -0500 (EST) Message-ID: <3DDC998A.4080309@dynamicsoft.com> Date: Thu, 21 Nov 2002 03:30:02 -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: Pete Cordell CC: midcom@ietf.org Subject: Re: [midcom] STUN issue 1: response codes References: <3DD9EA63.70808@dynamicsoft.com> <003c01c28fbd$a3b16ca0$0200000a@tkw> 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 We discussed this during the midcom meeting. There was support for using the more traditional three digit response code. Also, Eliott Lear had made some comments which, at the time I didn't understand, but afterwards, figured out that he didn't want a textual encoding, as you are suggesting, Pete. A middle ground approach is to actually use binary coded decimal here. That allows you to access the class directly, but requires you to do some multiplication and additions to get at an integral representation of the response code. Another approach is to retain a class field (8 bits, but values of 1-6 only allowed), separate from the actual numeric code (16 bits, but values 100-699 only). This is the same number of bits as BCD but requires no arithmetic operations. This is consistent with Patrik's suggestion to use a three-digit response code, but it merely provides a convenient encoding of such a code in a binary protocol. I suspect he would be fine with that. I am not sure, Pete, if this is what you were effectively saying below about dividing by 100. So, my current proposal is this class/code mechanism. Thoughts? -Jonathan R. Pete Cordell wrote: > I agree the IESG's proposal that the codes should be broken down into what > should happen next (e.g. retry, give up etc) rather than what caused them. > > However, as STUN is binary and SMTP etc are text, I don't think this implies > that they need to use the regular text based 3 digit code. (The format is > really already aligned, but just uses a more binary friendly base 256 > instead of base 10.) > >>From a debug point of view, it's probably easier for someone to look at the > current class based scheme rather than having to work out that 0x1A4 is a > class 400 error. (I would prefer to see the class codes divided by 100, > e.g. 400 -> 4, 500 -> 5 etc.) > > Still, dividing by 10 is no great hardship nowadays, so if it keeps people > happy, it's OK by me. > > Pete. > > ----- Original Message ----- > From: "Jonathan Rosenberg" > To: > Sent: 19 November 2002 07:38 > Subject: [midcom] STUN issue 1: response codes > > > >>Folks, >> >>As Melinda pointed out, there were several comments from IESG that >>require fixing in STUN. A few probably merit group discussion. I will be >>sending a separate email on each of those, proposing my solution, and >>will also discuss tomorrow. >> >>The first issue is response code handling. STUN specifies a new >>structure, using explicitly defined class and code values. This is >>similar to, but deviates from, more conventional three-digit reporting >>used in SMTP, SIP, HTTP and others. The IESG comment was that we should >>align here. >> >>I am inclined to agree. So, I propose we revert to a standard three >>digit code, and define the specific 400 class response codes we need. We >>also define the 500 class, but don't populate it with any respaonse >>codes, for potential future use. We ignore the 300 and 600 classes, as >>they are not applicable to STUN (anywya the usage of 300 class responses >>differs between SMTP and SIP/HTTP, so best to stay away from that...) >> >>Anyone object? >> >>-Jonathan R. >>-- >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >>Chief Scientist First Floor >>dynamicsoft East Hanover, NJ 07936 >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >>_______________________________________________ >>midcom mailing list >>midcom@ietf.org >>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 Thu Nov 21 03:39:25 2002 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 DAA25522 for ; Thu, 21 Nov 2002 03:39:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAL8fiQ30797 for midcom-archive@odin.ietf.org; Thu, 21 Nov 2002 03:41:44 -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 gAL8Z7v29927; Thu, 21 Nov 2002 03:35:07 -0500 Received: from ietf.org ([132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAL8Vav29743 for ; Thu, 21 Nov 2002 03:31:57 -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 DAA25274 for ; Thu, 21 Nov 2002 03:28:05 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.58]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAL8UkYH005544; Thu, 21 Nov 2002 03:30:46 -0500 (EST) Message-ID: <3DDC99B3.1000701@dynamicsoft.com> Date: Thu, 21 Nov 2002 03:30:43 -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: Pete Cordell CC: midcom@ietf.org Subject: Re: [midcom] STUN issue #3: FLAG extensibility References: <3DD9EF9B.7010905@dynamicsoft.com> <003b01c28fbd$a2ce1180$0200000a@tkw> 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 Yes, we agreed at the meeting that what you suggest is better. -Jonathan R. Pete Cordell wrote: > Jonathan, > > There should not be a need for this type of method as the TLV encoding of > the parameter can tell you how many flags words there are. However, the > spec could mention that there could be more than one word worth of flags. > > Pete. > > ----- Original Message ----- > From: "Jonathan Rosenberg" > To: > Sent: 19 November 2002 08:00 > Subject: [midcom] STUN issue #3: FLAG extensibility > > > >>The STUN spec has a flag attribute which is a fixed 32 bits. Once we run >>out, thats it. The IESG had asked if this can be made extensible. >> >>Proposal: Add an "E" flag which, when one, adds another 32 bits of >>flags. Of course, that additional 32 bits also has "E", so there is >>unlimited flags. >> >>-Jonathan R. >>-- >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >>Chief Scientist First Floor >>dynamicsoft East Hanover, NJ 07936 >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >>_______________________________________________ >>midcom mailing list >>midcom@ietf.org >>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 Thu Nov 21 03:43:30 2002 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 DAA25669 for ; Thu, 21 Nov 2002 03:43:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAL8joJ30998 for midcom-archive@odin.ietf.org; Thu, 21 Nov 2002 03:45:50 -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 gAL8dDv30659; Thu, 21 Nov 2002 03:39: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 gAL8WWv29806 for ; Thu, 21 Nov 2002 03:32:32 -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 DAA25286 for ; Thu, 21 Nov 2002 03:29:42 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.58]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAL8WNYH005547; Thu, 21 Nov 2002 03:32:23 -0500 (EST) Message-ID: <3DDC9A14.5050009@dynamicsoft.com> Date: Thu, 21 Nov 2002 03:32:20 -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: asimu@cisco.com CC: midcom@ietf.org Subject: Re: [midcom] STUN issue #7: recommended stateless server procedures References: <001301c28ff7$4f6246d0$c1422acc@amer.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 inline. Adina Simu (asimu) wrote: >>The STUN specification doesn't give any specific algorithm >>for doing a >>stateless server. Stateless operation requires some way to hand out >>usernames and passwords without storing them. >> >>Since it is easy to do this wrong, Steve Bellovin recommedned an >>algorithm. The algorithm also allows for determination of the >>source IP >>address used for the TLS exchange, needed to handle another >>one of the >>open issues. His algorithm is: >> >>username = > > > (sorry, I'm being very dense today) > > Why is rounded-time needed? To prevent people from reusing old usernames. They are supposed to have an expiration time. > > Does this somehow imply reliable time? Reliable? It doesn't require any clock synchronization, if thats what you mean. It does require maintaining the clock across reboots if you want the username to be valid across reboots, which you do. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Nov 21 03:46:13 2002 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 DAA25733 for ; Thu, 21 Nov 2002 03:46:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAL8mWS31276 for midcom-archive@odin.ietf.org; Thu, 21 Nov 2002 03:48:32 -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 gAL8fsv30814; Thu, 21 Nov 2002 03:41: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 gAL8bZv30414 for ; Thu, 21 Nov 2002 03:37:35 -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 DAA25452 for ; Thu, 21 Nov 2002 03:34:44 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.58]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAL8bFYH005550; Thu, 21 Nov 2002 03:37:16 -0500 (EST) Message-ID: <3DDC9B39.4060703@dynamicsoft.com> Date: Thu, 21 Nov 2002 03:37:13 -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: "Panayiotis A. Thermos" CC: midcom@ietf.org Subject: Re: [midcom] STUN issue #7: recommended stateless server procedures 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 Panayiotis A. Thermos wrote: > I assume that the prefix would be a random string of length 12 characters > or more > to strengthen the "username" value. Strengthen, as in, provides some security properties? Maybe I'm just too tired, but all that would do is add some salt to the input to an hmac. I don't think that provides any security benefits. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Nov 21 05:50:02 2002 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 FAA27716 for ; Thu, 21 Nov 2002 05:50:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALAqCU05794 for midcom-archive@odin.ietf.org; Thu, 21 Nov 2002 05:52: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 gALAjDv05622; Thu, 21 Nov 2002 05:45: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 gALAgYv05554 for ; Thu, 21 Nov 2002 05:42:34 -0500 Received: from tungsten.btinternet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27592 for ; Thu, 21 Nov 2002 05:39:23 -0500 (EST) Received: from host213-122-171-158.in-addr.btopenworld.com ([213.122.171.158] helo=tkw) by tungsten.btinternet.com with smtp (Exim 3.22 #16) id 18EomQ-0004zD-00; Thu, 21 Nov 2002 10:41:55 +0000 Message-ID: <008901c2914a$a6382520$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" Cc: References: <3DD9EA63.70808@dynamicsoft.com> <003c01c28fbd$a3b16ca0$0200000a@tkw> <3DDC998A.4080309@dynamicsoft.com> Subject: Re: [midcom] STUN issue 1: response codes Date: Thu, 21 Nov 2002 10:40:33 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 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 Jonathan, My main concern is that it doesn't take on a split personality between a binary and text protocol which I think would lead to confusion among implementers. I almost like your suggestion, but I would make the range of the numeric code only 00-99 so that both the class and numeric value were needed to work out the actual error. Iterating a few times, I end up with: - a class field (3 bits, values of 1-6 only allowed), - separate per class numeric code 8 bits, but values 00-99 only. encoded something like: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |Class| Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason Phrase (variable) .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This avoids duplication of the class in the numeric value (which would be another source of confusion), and is very close to in philosophy to the 3 digit error code, but is still binary. Pete. ----- Original Message ----- From: "Jonathan Rosenberg" To: "Pete Cordell" Cc: Sent: 21 November 2002 08:30 Subject: Re: [midcom] STUN issue 1: response codes > We discussed this during the midcom meeting. There was support for using > the more traditional three digit response code. Also, Eliott Lear had > made some comments which, at the time I didn't understand, but > afterwards, figured out that he didn't want a textual encoding, as you > are suggesting, Pete. > > A middle ground approach is to actually use binary coded decimal here. > That allows you to access the class directly, but requires you to do > some multiplication and additions to get at an integral representation > of the response code. > > Another approach is to retain a class field (8 bits, but values of 1-6 > only allowed), separate from the actual numeric code (16 bits, but > values 100-699 only). This is the same number of bits as BCD but > requires no arithmetic operations. This is consistent with Patrik's > suggestion to use a three-digit response code, but it merely provides a > convenient encoding of such a code in a binary protocol. I suspect he > would be fine with that. I am not sure, Pete, if this is what you were > effectively saying below about dividing by 100. > > So, my current proposal is this class/code mechanism. > > Thoughts? > > -Jonathan R. > > Pete Cordell wrote: > > I agree the IESG's proposal that the codes should be broken down into what > > should happen next (e.g. retry, give up etc) rather than what caused them. > > > > However, as STUN is binary and SMTP etc are text, I don't think this implies > > that they need to use the regular text based 3 digit code. (The format is > > really already aligned, but just uses a more binary friendly base 256 > > instead of base 10.) > > > >>From a debug point of view, it's probably easier for someone to look at the > > current class based scheme rather than having to work out that 0x1A4 is a > > class 400 error. (I would prefer to see the class codes divided by 100, > > e.g. 400 -> 4, 500 -> 5 etc.) > > > > Still, dividing by 10 is no great hardship nowadays, so if it keeps people > > happy, it's OK by me. > > > > Pete. > > > > ----- Original Message ----- > > From: "Jonathan Rosenberg" > > To: > > Sent: 19 November 2002 07:38 > > Subject: [midcom] STUN issue 1: response codes > > > > > > > >>Folks, > >> > >>As Melinda pointed out, there were several comments from IESG that > >>require fixing in STUN. A few probably merit group discussion. I will be > >>sending a separate email on each of those, proposing my solution, and > >>will also discuss tomorrow. > >> > >>The first issue is response code handling. STUN specifies a new > >>structure, using explicitly defined class and code values. This is > >>similar to, but deviates from, more conventional three-digit reporting > >>used in SMTP, SIP, HTTP and others. The IESG comment was that we should > >>align here. > >> > >>I am inclined to agree. So, I propose we revert to a standard three > >>digit code, and define the specific 400 class response codes we need. We > >>also define the 500 class, but don't populate it with any respaonse > >>codes, for potential future use. We ignore the 300 and 600 classes, as > >>they are not applicable to STUN (anywya the usage of 300 class responses > >>differs between SMTP and SIP/HTTP, so best to stay away from that...) > >> > >>Anyone object? > >> > >>-Jonathan R. > >>-- > >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > >>Chief Scientist First Floor > >>dynamicsoft East Hanover, NJ 07936 > >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >>http://www.jdrosen.net PHONE: (973) 952-5000 > >>http://www.dynamicsoft.com > >> > >>_______________________________________________ > >>midcom mailing list > >>midcom@ietf.org > >>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 Thu Nov 21 05:59:22 2002 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 FAA27836 for ; Thu, 21 Nov 2002 05:59:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALB1Vl06237 for midcom-archive@odin.ietf.org; Thu, 21 Nov 2002 06:01: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 gALAw6v05988; Thu, 21 Nov 2002 05:58: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 gALAtfv05918 for ; Thu, 21 Nov 2002 05:55:41 -0500 Received: from einsteinium (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27791 for ; Thu, 21 Nov 2002 05:53:00 -0500 (EST) Received: from host213-122-171-158.in-addr.btopenworld.com ([213.122.171.158] helo=tkw) by einsteinium with smtp (Exim 3.22 #16) id 18Eoza-0006FG-00; Thu, 21 Nov 2002 10:55:30 +0000 Message-ID: <00aa01c2914c$8c0d0240$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" , "Panayiotis A. Thermos" Cc: References: <3DDC9B39.4060703@dynamicsoft.com> Subject: Re: [midcom] STUN issue #7: recommended stateless server procedures Date: Thu, 21 Nov 2002 10:47:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 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 I guess using a different prefix each time could make sure that the same user name and password are not given out to two different hosts behind the same NAT box. That would be very possible if the IP part didn't include the port. Vaguely possible if the IP part did include the port. Pete. ----- Original Message ----- From: "Jonathan Rosenberg" To: "Panayiotis A. Thermos" Cc: Sent: 21 November 2002 08:37 Subject: Re: [midcom] STUN issue #7: recommended stateless server procedures > > > Panayiotis A. Thermos wrote: > > I assume that the prefix would be a random string of length 12 characters > > or more > > to strengthen the "username" value. > > Strengthen, as in, provides some security properties? Maybe I'm just too > tired, but all that would do is add some salt to the input to an hmac. I > don't think that provides any security benefits. > > -Jonathan R. > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > 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 Nov 21 11:29:31 2002 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 LAA09229 for ; Thu, 21 Nov 2002 11:29:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALGVh927254 for midcom-archive@odin.ietf.org; Thu, 21 Nov 2002 11:31:43 -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 gALGS2v26949; Thu, 21 Nov 2002 11:28:02 -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 gALGMtv26585 for ; Thu, 21 Nov 2002 11:22:55 -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 LAA08779 for ; Thu, 21 Nov 2002 11:20:12 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gALGMkYH005710; Thu, 21 Nov 2002 11:22:46 -0500 (EST) Message-ID: <3DDD0853.9050405@dynamicsoft.com> Date: Thu, 21 Nov 2002 11:22:43 -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: "Christopher A. Martin" CC: "'Panayiotis A. Thermos'" , "'Melinda Shore'" , midcom@ietf.org Subject: Re: [midcom] STUN issue #6: Client certs considered harmful References: <002f01c290ad$0201a780$9a00a8c0@ws041v4569> 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 Christopher A. Martin wrote: > I understand. > > It is just my personal opinion that the concept of this type of ping > could be considered a violation of many security policies in place that > could be abused by users behind networks not intended to use it. Then > again, it could be blocked by policies at the security enforcement > point. I don't believe it to be simply a "ping" tool, it provides > information to internal users in order to provide > traversal/circumvention that may not be authorized. So, let me understand. You are saying that there may be an enterprise that has a NAT. It has a policy which says that "we don't want our users using this STUN thing". There is a STUN server outside the network that users are trying to contact. The STUN server is not run by the enterprise. It would appear to me that having the STUN server authenticate the client doesn't address this issue in any way whatsoever. Since the STUN server and enterprise are different providers, what good is authentication. THere is no trust relationship there at all. If the enterprise wants to block STUN, it could turn off access to port 3478, the default stun port. This is the same thing an enterprise would do to disable HTTP, or POP, or IMAP, or whatever. It has the same issues and limitations as for those protocols. So, please explain to me how authentication has anything to do with this. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Nov 21 11:34:45 2002 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 LAA09545 for ; Thu, 21 Nov 2002 11:34:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALGavr27553 for midcom-archive@odin.ietf.org; Thu, 21 Nov 2002 11:36:57 -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 gALGUAv27066; Thu, 21 Nov 2002 11:30:10 -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 gALGOLv26695 for ; Thu, 21 Nov 2002 11:24:21 -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 LAA08871 for ; Thu, 21 Nov 2002 11:21:37 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.70]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gALGOBYH005713; Thu, 21 Nov 2002 11:24:15 -0500 (EST) Message-ID: <3DDD08A8.2050906@dynamicsoft.com> Date: Thu, 21 Nov 2002 11:24:08 -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: Pete Cordell CC: "Panayiotis A. Thermos" , midcom@ietf.org Subject: Re: [midcom] STUN issue #7: recommended stateless server procedures References: <3DDC9B39.4060703@dynamicsoft.com> <00aa01c2914c$8c0d0240$0200000a@tkw> 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 OK, this is a plausible explanation on use. -Jonathan R. Pete Cordell wrote: > I guess using a different prefix each time could make sure that the same > user name and password are not given out to two different hosts behind the > same NAT box. > > That would be very possible if the IP part didn't include the port. Vaguely > possible if the IP part did include the port. > > Pete. > > ----- Original Message ----- > From: "Jonathan Rosenberg" > To: "Panayiotis A. Thermos" > Cc: > Sent: 21 November 2002 08:37 > Subject: Re: [midcom] STUN issue #7: recommended stateless server procedures > > > >> >>Panayiotis A. Thermos wrote: >> >>>I assume that the prefix would be a random string of length 12 >> > characters > >>>or more >>>to strengthen the "username" value. >> >>Strengthen, as in, provides some security properties? Maybe I'm just too >>tired, but all that would do is add some salt to the input to an hmac. I >>don't think that provides any security benefits. >> >>-Jonathan R. >> >> >> >>-- >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >>Chief Scientist First Floor >>dynamicsoft East Hanover, NJ 07936 >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >>_______________________________________________ >>midcom mailing list >>midcom@ietf.org >>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 Thu Nov 21 11:54:46 2002 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 LAA10258 for ; Thu, 21 Nov 2002 11:54:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALGuxc29565 for midcom-archive@odin.ietf.org; Thu, 21 Nov 2002 11:56:59 -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 gALGnAv29168; Thu, 21 Nov 2002 11:49:10 -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 gALGkgv28996 for ; Thu, 21 Nov 2002 11:46:42 -0500 Received: from dnsmx1rrc.telcordia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09951 for ; Thu, 21 Nov 2002 11:43:58 -0500 (EST) Received: from notes800.cc.telcordia.com (notes800a.cc.telcordia.com [128.96.79.8]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id LAA07680; Thu, 21 Nov 2002 11:45:59 -0500 (EST) Subject: Re: [midcom] STUN issue #7: recommended stateless server procedures To: Jonathan Rosenberg Cc: midcom@ietf.org, "Panayiotis A. Thermos" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Panayiotis A. Thermos" Date: Thu, 21 Nov 2002 11:48:59 -0500 X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at 11/21/2002 11:46:00 AM 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: , Yes, "strengthen" in terms of providing randomness to protect against prediction attacks. Peter Thermos Jonathan Rosenberg To: "Panayiotis A. Thermos" Thermos/Telcordia) Subject: Re: [midcom] STUN issue #7: recommended 11/21/2002 stateless server procedures 03:37 AM Panayiotis A. Thermos wrote: > I assume that the prefix would be a random string of length 12 characters > or more > to strengthen the "username" value. Strengthen, as in, provides some security properties? Maybe I'm just too tired, but all that would do is add some salt to the input to an hmac. I don't think that provides any security benefits. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Nov 21 12:28:58 2002 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 MAA11577 for ; Thu, 21 Nov 2002 12:28:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALHVBd32308 for midcom-archive@odin.ietf.org; Thu, 21 Nov 2002 12:31:11 -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 gALHQhv31937; Thu, 21 Nov 2002 12:26: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 gALH6iv30011 for ; Thu, 21 Nov 2002 12:06:44 -0500 Received: from dnsmx1rrc.telcordia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10570 for ; Thu, 21 Nov 2002 12:04:00 -0500 (EST) Received: from notes800.cc.telcordia.com (notes800a.cc.telcordia.com [128.96.79.8]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id MAA16324; Thu, 21 Nov 2002 12:06:15 -0500 (EST) Subject: Re: [midcom] STUN issue #5: reflector attacks To: Jonathan Rosenberg Cc: midcom@ietf.org, "Panayiotis A. Thermos" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Panayiotis A. Thermos" Date: Thu, 21 Nov 2002 12:09:14 -0500 X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at 11/21/2002 12:06:16 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Thanks Jonathan. Jonathan Rosenberg To: "Panayiotis A. Thermos" Thermos/Telcordia) Subject: Re: [midcom] STUN issue #5: reflector attacks 11/21/2002 03:20 AM It was my understanding that he was referring to this: V. Paxson, "An analysis of using reflectors for distributed denial of service attacks," ACM Computer Communication Review , Vol. 31, July 2001. -Jonathan R. Panayiotis A. Thermos wrote: > Just for clarification purposes could you provide an example of such > attack? > > One scenario that I can think is where a malicious user generates multiple > STUN messages with the RESPONSE-ADDRESS attribute pointing to > a "victim" host then according to the current draft (and depending on the > implementation) the victim host will check the MESSAGE-INTEGRITY > field and it will be ignored since it is not a message that the victim > host > has generated. I'm not clear in what scenario the REFLECTED-FROM > will be most effective given that we already some infotmation from > previous interaction over SSL. > > There is also the case where a legitimate STUN response has to be > be send to another "trusted" multimedia component (other than the one > that generated the request), which is part of the end-user's environment. > This should be addressed seperately. > > Thanks for your help. > > > > > Jonathan > Rosenberg To: midcom@ietf.org > csoft.com> Subject: [midcom] STUN issue #5: reflector attacks > > 11/19/2002 > 03:22 AM > > > > > > > > STUN has a RESPONSE-ADDRESS attribute. This attribute is used by the > client to tell the server the IP/port where to send the response. This > can be used by an attacker as a reflector attack, to mask the true > source IP address of a dos attack. > > Steve Bellovin suggested that this is best dealt with by adding, to the > response, the source IP where the request came from, and to make sure > its integrity protected. This adds traceability. So, you can't prevent > this, but you can see the true source address. The proposal is to accept > his recommendation and add a REFLECTED-FROM attribute containing this > source address. > > Note that this source address can't actually be the one from the UDP > request (since thats easily spoofed). But rather, from the TLS exchange > that established the USERNAME used in the request. That requires state > in the server, OR a smart implementation which creates usernames that > contain this IP, along with an hmac over them to protect it. > > > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > 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 Thu Nov 21 12:44:32 2002 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 MAA12143 for ; Thu, 21 Nov 2002 12:44:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALHkix01587 for midcom-archive@odin.ietf.org; Thu, 21 Nov 2002 12:46:44 -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 gALHh9v01295; Thu, 21 Nov 2002 12:43: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 gALHZ6v32513 for ; Thu, 21 Nov 2002 12:35:06 -0500 Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11680 for ; Thu, 21 Nov 2002 12:32:21 -0500 (EST) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0H5X0095VSR9DD@firewall.wcom.com> for midcom@ietf.org; Thu, 21 Nov 2002 17:33:09 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H5X00M01SR8CY@dgismtp04.wcomnet.com>; Thu, 21 Nov 2002 17:33:08 +0000 (GMT) Received: from ws041v4569 ([166.44.57.203]) by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H5X00JQOSR6PZ@dgismtp04.wcomnet.com>; Thu, 21 Nov 2002 17:33:08 +0000 (GMT) Date: Thu, 21 Nov 2002 11:33:06 -0600 From: "Christopher A. Martin" Subject: RE: [midcom] STUN issue #6: Client certs considered harmful In-reply-to: <3DDD0853.9050405@dynamicsoft.com> To: "'Jonathan Rosenberg'" Cc: "'Panayiotis A. Thermos'" , "'Melinda Shore'" , midcom@ietf.org Message-id: <002b01c29184$0e611830$9a00a8c0@ws041v4569> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-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 already stated it could be blocked... and you are right no different than blocking any other service. It was just food for thought, nothing more, if it didn't provide any further concern to look into this further then no harm done, and as I said before I have more reading to do, this horse may have already been beaten to death, if so, my apologies. Chris -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Thursday, November 21, 2002 10:23 AM To: Christopher A. Martin Cc: 'Panayiotis A. Thermos'; 'Melinda Shore'; midcom@ietf.org Subject: Re: [midcom] STUN issue #6: Client certs considered harmful Christopher A. Martin wrote: > I understand. > > It is just my personal opinion that the concept of this type of ping > could be considered a violation of many security policies in place > that could be abused by users behind networks not intended to use it. > Then again, it could be blocked by policies at the security > enforcement point. I don't believe it to be simply a "ping" tool, it > provides information to internal users in order to provide > traversal/circumvention that may not be authorized. So, let me understand. You are saying that there may be an enterprise that has a NAT. It has a policy which says that "we don't want our users using this STUN thing". There is a STUN server outside the network that users are trying to contact. The STUN server is not run by the enterprise. It would appear to me that having the STUN server authenticate the client doesn't address this issue in any way whatsoever. Since the STUN server and enterprise are different providers, what good is authentication. THere is no trust relationship there at all. If the enterprise wants to block STUN, it could turn off access to port 3478, the default stun port. This is the same thing an enterprise would do to disable HTTP, or POP, or IMAP, or whatever. It has the same issues and limitations as for those protocols. So, please explain to me how authentication has anything to do with this. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org 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 Nov 21 13:11:10 2002 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 NAA13309 for ; Thu, 21 Nov 2002 13:11:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALIDOk03620 for midcom-archive@odin.ietf.org; Thu, 21 Nov 2002 13: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 gALI6Fv02727; Thu, 21 Nov 2002 13:06: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 gALI38v02617 for ; Thu, 21 Nov 2002 13:03:08 -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 NAA12724 for ; Thu, 21 Nov 2002 13:00:23 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gALI35YH005801; Thu, 21 Nov 2002 13:03:05 -0500 (EST) Message-ID: <3DDD1FD6.3030307@dynamicsoft.com> Date: Thu, 21 Nov 2002 13:03:02 -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: Pete Cordell CC: midcom@ietf.org Subject: Re: [midcom] STUN issue 1: response codes References: <3DD9EA63.70808@dynamicsoft.com> <003c01c28fbd$a3b16ca0$0200000a@tkw> <3DDC998A.4080309@dynamicsoft.com> <008901c2914a$a6382520$0200000a@tkw> 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 Pete Cordell wrote: > Jonathan, > > My main concern is that it doesn't take on a split personality between a > binary and text protocol which I think would lead to confusion among > implementers. > > I almost like your suggestion, but I would make the range of the numeric > code only 00-99 so that both the class and numeric value were needed to work > out the actual error. I thought about this; the main problem is that it will probably require a multiply-by-10 to get the complete response code. Now, that certainly depends on implementation, since you could keep them separate throughout the code.. > > Iterating a few times, I end up with: > > - a class field (3 bits, values of 1-6 only allowed), > - separate per class numeric code 8 bits, but values 00-99 only. > > encoded something like: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0 |Class| Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reason Phrase (variable) .. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > This avoids duplication of the class in the numeric value (which would be > another source of confusion), and is very close to in philosophy to the 3 > digit error code, but is still binary. I don't feel strongly, really, and could go either way. I will use your suggestion unless anyone has further comment. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Nov 25 08:26:20 2002 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 IAA27083 for ; Mon, 25 Nov 2002 08:26:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPDSY332493 for midcom-archive@odin.ietf.org; Mon, 25 Nov 2002 08:28: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 gAPDOlv32380; Mon, 25 Nov 2002 08:24:47 -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 gAPDLRv32225 for ; Mon, 25 Nov 2002 08:21:27 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26394; Mon, 25 Nov 2002 08:18:43 -0500 (EST) Message-Id: <200211251318.IAA26394@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 25 Nov 2002 08:18:43 -0500 Subject: [midcom] I-D ACTION:draft-ietf-midcom-protocol-eval-06.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : Middlebox Communications (MIDCOM) Protocol Evaluation Author(s) : M. Barnes Filename : draft-ietf-midcom-protocol-eval-06.txt Pages : 35 Date : 2002-11-21 This document provides an evaluation of the applicability of SNMP, RSIP, MEGACO, DIAMETER and COPS as the MIDCOM protocol. A summary of each of the proposed protocols against the MIDCOM requirements and MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-protocol-eval-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-protocol-eval-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-21133859.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-protocol-eval-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-protocol-eval-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-21133859.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Nov 25 08:45:35 2002 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 IAA27713 for ; Mon, 25 Nov 2002 08:45:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPDln001346 for midcom-archive@odin.ietf.org; Mon, 25 Nov 2002 08: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 gAPDi6v01178; Mon, 25 Nov 2002 08:44: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 gAPDe4v00931 for ; Mon, 25 Nov 2002 08:40:04 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27428 for ; Mon, 25 Nov 2002 08:37:19 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAPDeEU00421 for ; Mon, 25 Nov 2002 07:40:14 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Nov 2002 07:40:01 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CB00@zrc2c000.us.nortel.com> From: "Mary Barnes" To: midcom@ietf.org Subject: RE: [midcom] I-D ACTION:draft-ietf-midcom-protocol-eval-06.txt Date: Mon, 25 Nov 2002 07:40:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29488.26EF8650" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C29488.26EF8650 Content-Type: text/plain; charset="iso-8859-1" Hi all, The draft is now officially available. As I presented in the meeting last week, all comments should be received and WG discussion completed by this Friday, Nov. 29th, so comments should ideally be submitted early this week. A summary of the changes is available in the thread (which also provides a link to the word version with changes marked): http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg02807.htm l The plan is to get any updates made to the document and the updated document submitted by Friday, Dec. 6th and made available to the IESG the week of Dec. 8th. Regards, Mary. -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, November 25, 2002 7:19 AM Cc: midcom@ietf.org Subject: [midcom] I-D ACTION:draft-ietf-midcom-protocol-eval-06.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : Middlebox Communications (MIDCOM) Protocol Evaluation Author(s) : M. Barnes Filename : draft-ietf-midcom-protocol-eval-06.txt Pages : 35 Date : 2002-11-21 This document provides an evaluation of the applicability of SNMP, RSIP, MEGACO, DIAMETER and COPS as the MIDCOM protocol. A summary of each of the proposed protocols against the MIDCOM requirements and MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-protocol-eval-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-protocol-eval-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C29488.26EF8650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] I-D = ACTION:draft-ietf-midcom-protocol-eval-06.txt

Hi all,

The draft is now officially available.  As I = presented in the meeting last week, all comments should be received and = WG discussion completed by this Friday, Nov. 29th, so comments should = ideally be submitted early this week.  

A summary of the changes is available in the thread = (which also provides a link to the word version with changes marked): =

http://www1.ietf.org/mail-archive/working-groups/midco= m/current/msg02807.html

The plan is to get any updates made to the document = and the updated document submitted by Friday, Dec. 6th and made = available to the IESG the week of Dec. 8th. 

Regards,
Mary.

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Monday, November 25, 2002 7:19 AM
Cc: midcom@ietf.org
Subject: [midcom] I-D = ACTION:draft-ietf-midcom-protocol-eval-06.txt


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the Middlebox = Communication Working Group of the IETF.

        Title           : = Middlebox Communications (MIDCOM) Protocol Evaluation
        Author(s)       : M. = Barnes
        Filename        : = draft-ietf-midcom-protocol-eval-06.txt
        Pages           : = 35
        Date    =         : 2002-11-21
       =20
This document provides an evaluation of the = applicability of SNMP,
RSIP, MEGACO, DIAMETER and COPS as the MIDCOM = protocol. A summary
of each of the proposed protocols against the MIDCOM = requirements
and MIDCOM framework is provided.  Compliancy = of each of the
protocols against each requirement is detailed. A = conclusion
summarizes how each of the protocols fares in the = evaluation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-midcom-= protocol-eval-06.txt

To remove yourself from the IETF Announcement list, = send a message to
ietf-announce-request with the word unsubscribe in = the body of the message.

Internet-Drafts are also available by anonymous FTP. = Login with the username
"anonymous" and a password of your e-mail = address. After logging in,
type "cd internet-drafts" and then
        "get = draft-ietf-midcom-protocol-eval-06.txt".

A list of Internet-Drafts directories can be found = in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by = e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE = /internet-drafts/draft-ietf-midcom-protocol-eval-06.txt".
       =20
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.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

------_=_NextPart_001_01C29488.26EF8650-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Nov 25 08:52:39 2002 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 IAA27890 for ; Mon, 25 Nov 2002 08:52:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPDsqF01670 for midcom-archive@odin.ietf.org; Mon, 25 Nov 2002 08:54:52 -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 gAPDs7v01619; Mon, 25 Nov 2002 08:54: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 gAPDmNv01371 for ; Mon, 25 Nov 2002 08:48:23 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27728 for ; Mon, 25 Nov 2002 08:45:38 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gAPDmLKc016152 for ; Mon, 25 Nov 2002 05:48:21 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAY06880; Mon, 25 Nov 2002 05:42:38 -0800 (PST) Message-Id: <200211251342.AAY06880@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Mon, 25 Nov 2002 08:48:20 -0500 Subject: [midcom] Midcom proposal: please read 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: , There was a proposal made during the midcom session at the IETF meeting to shortcut the protocol selection process and just go with SNMPv3 as the midcom protocol. Consistent with IETF process, this is a decision to be made on the mailing list. I'd like to come to a decision within the next week or so (Thursday is Thanksgiving in the US and many people may be away this week). Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Nov 25 10:25:01 2002 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 KAA03213 for ; Mon, 25 Nov 2002 10:25:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPFRDe07650 for midcom-archive@odin.ietf.org; Mon, 25 Nov 2002 10:27:13 -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 gAPFNBv07504; Mon, 25 Nov 2002 10:23:11 -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 gAPFMdv07479 for ; Mon, 25 Nov 2002 10:22:39 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03018 for ; Mon, 25 Nov 2002 10:19:53 -0500 (EST) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAPFMaoh005358 for ; Mon, 25 Nov 2002 07:22:36 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAY08340; Mon, 25 Nov 2002 07:16:52 -0800 (PST) Message-Id: <200211251516.AAY08340@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Mon, 25 Nov 2002 10:22:34 -0500 Subject: [midcom] IETF 55 minutes 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: , Many thanks to Bob Penfield for his thorough minutes and for getting them out so quickly. The minutes are appended; comments and corrections to the mailing list. Thanks, Melinda ======== Minutes of midcom working group at 55th IETF Meeting, Atlanta, Georgia, USA Chaired by Melinda Shore (mshore@cisco.com) Reported by Bob Penfield (bpenfield@acmepacket.com), edited by Melinda Shore ============= Status update ------------- pre-midcom: - The STUN document has come back from the IESG with some issues that require a Working Group decision (see STUN section below) - SPAN has been cancelled due to lack of interest and activity on the list and due to intractable security problems. Protocol evaluation: - The protocol evaluation document came back from the IESG. The most significant issue was there desire for more detail in the SNMP discussion. Semantics: - The two semantics documents have been combined into a single document. Milestones: - The original milestone was to complete a protocol document by December which obviously will not be achieved. We do need to "choose" one of the candidate protocols as a based in the next month. - There was a discussion on whether the STUN document would have to go thru WGLC again. A couple of people felt that the changes required were not significant enough to warrant a new WGLC. ==================================== STUN - draft-ietf-midcom-stun-03.txt ------------------------------------ Jonathan Rosenberg went over the STUN issues raised by the IESG. Most of them are clarifications including text to point out the known limitations when both sides of a communication are behind the same NAT: The issues requiring resolution are: 1) Response Codes - the IESG felt that the response codes should conform to other IETF protocols (e.g. SIP, HTTP, etc). The proposed resolution is to define 4xx & 5xx class responses an behavior consistent with the other protocols. 1xx are to be avoided, 3xx do not apply. Currently, the error response and success response are 2 different messages so an error response would never contain a 2xx response code. One person was a little uncomfortable with not having 2xx response code (they will discuss offline). 2) Unknown Attributes. The spec says that unknown attributes should just be discarded. This is broken. Proposal is to send back an error response (with code like 420) and a list of unrecognized attributes. 3) Flags Extension. What happens when there are more than 32 flags? The proposal is to use the length in the TLV to indicate how many flags are present. There was some discussion about making the flags field shorter since we have committed to not extend the protocol, and whether implementers would ignore the length field. 4) No IANA procedures. Even if you are not going to allow extensions you need to say that. There is already some extensibility built in. It was proposed that a standards track RFC be required to extend it. Some felt it should require a new version of the protocol, but that was too extreme for many people. 5) Reflector Attack vulnerability with the RESPONSE_ADDRESS attribute. Proposal is too include a REFLECTED-FROM attribute to identify who sent the original request. This would be from the TLS connection that established the username and password. Some felt this was too complicated with little benefit. It was suggested that the STUN packets need to be easily identifiable so that routers could discard them. This issue requires further discussion on the mailing list. 6) Client Certificates are considered harmful. The spec currently says they MAY be used. Proposal is to change to "MUST NOT use". 7) No recommendations for stateless generation of username/password. Steve Bellovin has recommended an algorithm. The Proposal is to include the algorithm as non-normative text as an example of how one could do this. 8) Remove IPv6 Support. Since this is a short-term protocol to work around problem of IPv4 NATs, the IESG does not want IPv6 support. The proposal was to remove the v6 family. Some felt the address family should be removed altogether because people could hack in IPv6 support. 9) Discard Flag is broken. Was used to prime the NAT with suicide packets. It does not work because you need the response to know the packet got thru. Proposal is to remove the discard flag. Some of these issues require further list discussion, but they need to be resolved quickly so that the spec can proceed. ============================================================== Midcom protocol semantics - draft-ietf-midcom-semantics-00.txt -------------------------------------------------------------- Juergen Quittek presented the Semantics document issues. - There is now one combined semantics document. - There is one transaction set for Firewall and NAT. - Works on first-come, first-served basis. - Goal is to keep the semantics simple & stupid. - Why PRR? Need to do the binding to complete the 5-tuple in order for agent to pass on signaling message. Is Twice-NAT required? - Group Transactions have been removed. Group creation is now implicit in PRR and PER transactions. - Wildcarding needs list discussion - Return Values: Should full 5-tuple be included in response so that FW/NAT function is transparent to the agent? - Should PER be split into two requests? - Message Queuing. Transactions need to be atomic and operate on first come first served basis. - Capabilities exchange: is list in spec complete? - Encryption Method - It was pointed out that the encryption method and keying needs to be decoupled. Issue needs list discussion. It was reported that the NSIS WG had discussed using CASP and TIST to talk to FW/NATs. =================================================================== Midcom protocol evaluation - draft-ietf-midcom-protocol-eval-05.txt ------------------------------------------------------------------- Mary Barnes presented status of the protocol evaluation document. The document case back from the IESG. The main issue is that they wanted a revamp of the SNMP discussion to include more detail and background of how it meets the requirements. A new version (-06) will be posted which include the SNMP changes, and other miscellaneous updates. It will also reflect the WG decision that RSIP is not appropriate. Feedback is needed by November 29th so that a revised version can be submitted. It was asked if the document should recommend a protocol, but the protocol selection process (see below) will "choose" one. It was also asked if there could be a weighting of the requirements, but it was felt that that would be too subjective. ================================= Midcom protocol selection/process --------------------------------- The proposed process for selecting a protocol would be to eliminate any unsuitable candidates (as we have done with RSIP), and then to choose from the remaining candidates. Would like to eliminate at least one more. Other considerations: - would we expect to see the candidate protocol already present in the device (middlebox and/or agent). - what is the level of standardization of the candidate protocol - other intangibles It was suggested that the directionality problems and awkwardness of session establishment procedures in COPS make it unsuitable. The chair pointed out that we need to make progress. People need to read the documents and participate. Not choosing any protocol is also an option (better none than one that is never used). Some people felt we should have the option of developing a protocol. To do that, we must demonstrate that all the candidates are unsuitable. It was pointed out that of all the candidates, the one which is most likely to be there already is SNMP, and that we should just propose that SNMP be the selected protocol. Others pointed out that SNMPv3 not widely used and it is a big leap from SNMPv2 to v3. It was also pointed out that SNMP is not used very much for configuration. There were a number of suggestions for things that could be done in the eval document for providing more information to make a decision from. This included describing how each protocol would be used in a midcom environment. However, it was pointed out that there has been fair opportunity to do that and that it would only delay the process. The COPS supporters felt that if you look at protocol reuse, COPS already has the policy rule exchange needed for midcom. It was suggested that the bar was set too high in not allowing us to consider writing a new protocol. This too though might have the same problem in selecting from a set of existing proprietary protocols. The commenter listed a number of devices which already support SNMPv3. Discussion to be continued on the mailing list. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Mon Nov 25 16:33:22 2002 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 QAA26849 for ; Mon, 25 Nov 2002 16:33:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAPLZe831423 for midcom-archive@odin.ietf.org; Mon, 25 Nov 2002 16:35:40 -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 gAPLUgv31117; Mon, 25 Nov 2002 16:30:42 -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 gAPLS5v31040 for ; Mon, 25 Nov 2002 16:28:05 -0500 Received: from lutetium (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26418 for ; Mon, 25 Nov 2002 16:25:16 -0500 (EST) Received: from host213-122-56-81.in-addr.btopenworld.com ([213.122.56.81] helo=tkw) by lutetium with smtp (Exim 3.22 #16) id 18GQlU-0002Uq-00; Mon, 25 Nov 2002 21:27:37 +0000 Message-ID: <000201c294c9$791d5ce0$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" Cc: References: <3DD9EA63.70808@dynamicsoft.com> <003c01c28fbd$a3b16ca0$0200000a@tkw> <3DDC998A.4080309@dynamicsoft.com> <008901c2914a$a6382520$0200000a@tkw> <3DDD1FD6.3030307@dynamicsoft.com> Subject: Re: [midcom] STUN issue 1: response codes Date: Mon, 25 Nov 2002 17:50:14 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 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 please see comments inline... Pete ----- Original Message ----- From: "Jonathan Rosenberg" To: "Pete Cordell" Cc: Sent: 21 November 2002 18:03 Subject: Re: [midcom] STUN issue 1: response codes > > > Pete Cordell wrote: > > Jonathan, > > > > My main concern is that it doesn't take on a split personality between a > > binary and text protocol which I think would lead to confusion among > > implementers. > > > > I almost like your suggestion, but I would make the range of the numeric > > code only 00-99 so that both the class and numeric value were needed to work > > out the actual error. > > I thought about this; the main problem is that it will probably require > a multiply-by-10 to get the complete response code. Now, that certainly > depends on implementation, since you could keep them separate throughout > the code.. > To get the complete code you would just operate on the entire 11 bits (3+8) of the error code. (This is an extra bit over what you'd need to encode 699 in binary - 1010111011 - but this is no issue.) error_class = ( error_word & 0x700 ) >> 8; per_class_error = error_word & 0xff; But this is not really the issue as any device that is likely to use STUN will won't have any problems handling division by 100 etc, which would be required if it was a pure decimal number. The real benefit is avoiding producing a schizophrenic protocol that is mostly binary, but has a little text for no good reason. That would lead to confusion amongst implementers and therefore interoperability problems. > > > > Iterating a few times, I end up with: > > > > - a class field (3 bits, values of 1-6 only allowed), > > - separate per class numeric code 8 bits, but values 00-99 only. > > > > encoded something like: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | 0 |Class| Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Reason Phrase (variable) .. > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > This avoids duplication of the class in the numeric value (which would be > > another source of confusion), and is very close to in philosophy to the 3 > > digit error code, but is still binary. > > I don't feel strongly, really, and could go either way. I will use your > suggestion unless anyone has further comment. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 26 02:13:04 2002 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 CAA22962 for ; Tue, 26 Nov 2002 02:13:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQ7FQr03670 for midcom-archive@odin.ietf.org; Tue, 26 Nov 2002 02:15: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 gAQ7F3v03659; Tue, 26 Nov 2002 02:15: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 gAQ7EEv03635 for ; Tue, 26 Nov 2002 02:14:14 -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 CAA22951 for ; Tue, 26 Nov 2002 02:11:21 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAQ7E5YH008144; Tue, 26 Nov 2002 02:14:06 -0500 (EST) Message-ID: <3DE31F3A.6020602@dynamicsoft.com> Date: Tue, 26 Nov 2002 02:14:02 -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: Pete Cordell CC: Melinda Shore , midcom@ietf.org Subject: Re: [midcom] STUN issue #4: IANA procedures References: <200211191424.AAV79702@mira-sjc5-4.cisco.com> <001d01c28fe1$f02eaec0$0200000a@tkw> 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 This was contentious during the meeting, and merits further discussion. Upon further reflection, I too am inclined to agree that the IANA registry serves no purpose. I believe the protocol must be extensible in the sense that we can add things if necessary, but that is different from making it easy to be extended - i.e., that the protocol was built with the intent that there would be lots of extensions. An IANA registry is really needed only in the latter case. So, I would propose that we add an IANA considerations section stating that there are no IANA registries defined. -Jonathan R. Pete Cordell wrote: > I'm inclined to agree with you Melinda. (When I did SPAN I ripped most of > the extensibility stuff out of it for this reason.) > > I don't see why we can't define such procedures as and when they become > necessary - hopefully they won't - in a separate RFC (or a STUN v2 if > required). That should raise the barrier for minor extensions that are > feature creep with little merit. In other words, it would mean that it > would require significant group consensus before the changes could be made. > > Pete. > > ----- Original Message ----- > From: "Melinda Shore" > To: "Jonathan Rosenberg" > Cc: > Sent: 19 November 2002 14:29 > Subject: Re: [midcom] STUN issue #4: IANA procedures > > > >>>Proposal: history shows that protocols that are often extended even when >>>not originally intended. As such, we should prepare for this better, and >>>therefore, define an iana registry for (1) messages, (2) resposne codes, >>>(3) attributes, (4) flags. >> >>I am unenthusiastic about this. From talking with various >>implementers it's pretty clear that even though the protocol >>isn't standardized yet and even though we're clear (are we >>not?) that this is to be a short-lived protocol and that it >>has a number of serious limitations that make it unsuitable >>for longer-term use, we're already looking at feature >>creep. I'd really like to discourage this or, at least, >>avoid suggesting that the working group thinks this is a >>good thing. >> >>If somebody wants to talk about the need to have a >>reasonable mechanism for fixing errors that are discovered >>in the future that's reasonable, but extending STUN? That's >>a problem. >> >>Melinda >>_______________________________________________ >>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 Tue Nov 26 02:13:36 2002 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 CAA23001 for ; Tue, 26 Nov 2002 02:13:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQ7FwP03686 for midcom-archive@odin.ietf.org; Tue, 26 Nov 2002 02:15:58 -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 gAQ7CSv03603; Tue, 26 Nov 2002 02:12: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 gAQ7Bmv03555 for ; Tue, 26 Nov 2002 02:11:48 -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 CAA22867 for ; Tue, 26 Nov 2002 02:08:55 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAQ7BcYH008141; Tue, 26 Nov 2002 02:11:39 -0500 (EST) Message-ID: <3DE31EA7.5050005@dynamicsoft.com> Date: Tue, 26 Nov 2002 02:11:35 -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: Jonathan Rosenberg CC: midcom@ietf.org Subject: Re: [midcom] STUN issue #5: reflector attacks References: <3DD9F4DE.6030207@dynamicsoft.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 This issue was discussed at length during the meeting in Atlanta. There was some concern raised that it didnt provide proper traceability. The algorithm suggested by Steve will allow the recipient of the response to determine the IP address where the TLS connection came from. That can be completely unrelated to where the UDP binding request came from. For example, I could open a TLS connection, get a username/password, and email that to someone. They could use that to launch an attack. The target would see my identity, not that of the attacker. Furthermore, because of NAT, the source IP in the TLS connection would only point to the outermost NAT, not the specific user within. I think that, in the end, these limitations are just fine. It is not the job of STUN to be an intrusion detection system. STUN nearly needs to point the finger to the "next person to whom the subpoena should go". If this is the enterprise that owns the NAT where the TLS connection came from, so be it. Its the NAT-vendors problems to maintain logs to trace the actual source. Its then the email server vendors problem to figure out who they mailed the username/password to. So, even if its not the actual source, the username provides a useful point of contact for further investigation in the source of an attack, and thats sufficient. Thus, it is my proposal that we retain the mechanism described below. -Jonathan R. Jonathan Rosenberg wrote: > STUN has a RESPONSE-ADDRESS attribute. This attribute is used by the > client to tell the server the IP/port where to send the response. This > can be used by an attacker as a reflector attack, to mask the true > source IP address of a dos attack. > > Steve Bellovin suggested that this is best dealt with by adding, to the > response, the source IP where the request came from, and to make sure > its integrity protected. This adds traceability. So, you can't prevent > this, but you can see the true source address. The proposal is to accept > his recommendation and add a REFLECTED-FROM attribute containing this > source address. > > Note that this source address can't actually be the one from the UDP > request (since thats easily spoofed). But rather, from the TLS exchange > that established the USERNAME used in the request. That requires state > in the server, OR a smart implementation which creates usernames that > contain this IP, along with an hmac over them to protect it. > > > > -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 26 06:05:45 2002 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 GAA26930 for ; Tue, 26 Nov 2002 06:05:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQB7xn17602 for midcom-archive@odin.ietf.org; Tue, 26 Nov 2002 06:07:59 -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 gAQB7Wv17592; Tue, 26 Nov 2002 06:07:32 -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 gAQB6Zv16949 for ; Tue, 26 Nov 2002 06:06:35 -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 GAA26894 for ; Tue, 26 Nov 2002 06:03:50 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAQB6KY84872; Tue, 26 Nov 2002 12:06:20 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B57DF5B8F2; Tue, 26 Nov 2002 12:04:44 +0100 (CET) Message-ID: <3DE3553A.7020804@ccrle.nec.de> Date: Tue, 26 Nov 2002 12:04:26 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE MIME-Version: 1.0 To: Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] IETF 55 minutes References: <200211251516.AAY08340@mira-sjc5-4.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit 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 have just done a quick look through the minutes w.r.t.the semantics. My memories are different from some issues written below. Further comments are inline and thanks to Bob for writing down the minutes Kind Regards Martin > ============================================================== > Midcom protocol semantics - draft-ietf-midcom-semantics-00.txt > -------------------------------------------------------------- > Juergen Quittek presented the Semantics document issues. Juergen Quittek didn't present the semantics. Furthermore the semantics doc was a combined work of Jürgen, Tom and Martin and presented by Martin. > > - There is now one combined semantics document. > > - There is one transaction set for Firewall and NAT. > > - Works on first-come, first-served basis. > > - Goal is to keep the semantics simple & stupid. > > - Why PRR? Need to do the binding to complete the 5-tuple in order > for agent to pass on signaling message. Is Twice-NAT required? The question was wether the return values should reflect the presence of a twice-NAT or not. > > - Group Transactions have been removed. Group creation is now implicit > in PRR and PER transactions. Group transactions have not been removed and group creation is currently not implicit. This was a question if we should remove the Group establishment transaction or not. I think that there has been no consensus during the meeting to change anyhting in the semantics. The decissions have been moved to the list. > > - Wildcarding needs list discussion OK. > > - Return Values: Should full 5-tuple be included in response so > that FW/NAT function is transparent to the agent? > > - Should PER be split into two requests? > > - Message Queuing. Transactions need to be atomic and operate on > first come first served basis. May be it is better to write this a question, since there was no consensus on this. > > - Capabilities exchange: is list in spec complete? > > - Encryption Method - It was pointed out that the encryption method and > keying needs to be decoupled. Issue needs list discussion. > > It was reported that the NSIS WG had discussed using CASP and TIST to talk > to FW/NATs. > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 26 06:11:10 2002 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 GAA27001 for ; Tue, 26 Nov 2002 06:11:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQBDOv17827 for midcom-archive@odin.ietf.org; Tue, 26 Nov 2002 06: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 gAQBD4v17815; Tue, 26 Nov 2002 06:13: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 gAQBCav17793 for ; Tue, 26 Nov 2002 06:12:36 -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 GAA26980 for ; Tue, 26 Nov 2002 06:09:51 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAQBCMY85190; Tue, 26 Nov 2002 12:12:22 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 723E851635; Tue, 26 Nov 2002 12:10:46 +0100 (CET) Message-ID: <3DE35695.1010706@ccrle.nec.de> Date: Tue, 26 Nov 2002 12:10:13 +0100 From: Martin Stiemerling Organization: NEC Europe Ltd. NL-E User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE MIME-Version: 1.0 To: Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] Midcom proposal: please read References: <200211251342.AAY06880@mira-sjc5-4.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 I have a question regarding SNMP and setting multiple values at the same time. Perhaps this is a very basic question, but I see some problems here. For MIDCOM it is required to configure all data of the policy rule at the same time and to get the data really configured (all or nothing principle). In SNMP you can set one value and check wether this has been set properly or not. What about SNMP if you have to set 5-tuples at the same time. Is there any mechanism in the SNMP protocol that allow this or do we have to create our own mechanism? A word ahead: I would appreciate detailed answers and not just plain answers like "It works because it is defined", since I'm not aware about all geat features in SNMPv3. Martin Melinda Shore wrote: > There was a proposal made during the midcom session at the > IETF meeting to shortcut the protocol selection process and > just go with SNMPv3 as the midcom protocol. Consistent with > IETF process, this is a decision to be made on the mailing > list. I'd like to come to a decision within the next week > or so (Thursday is Thanksgiving in the US and many people > may be away this week). > > 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 Tue Nov 26 07:12:42 2002 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 HAA28193 for ; Tue, 26 Nov 2002 07:12:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQCEtp21463 for midcom-archive@odin.ietf.org; Tue, 26 Nov 2002 07:14:55 -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 gAQCESv21450; Tue, 26 Nov 2002 07:14: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 gAQCDhv21419 for ; Tue, 26 Nov 2002 07:13:43 -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 HAA28122 for ; Tue, 26 Nov 2002 07:10:59 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id gAQCCcCq007054; Tue, 26 Nov 2002 07:12:38 -0500 (EST) Date: Tue, 26 Nov 2002 07:12:38 -0500 (EST) From: Scott Bradner Message-Id: <200211261212.gAQCCcCq007054@newdev.harvard.edu> To: jdrosen@dynamicsoft.com, pete@tech-know-ware.com Subject: Re: [midcom] STUN issue #4: IANA procedures Cc: midcom@ietf.org, mshore@cisco.com In-Reply-To: <3DE31F3A.6020602@dynamicsoft.com> 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: , > So, I would propose that we add an IANA considerations section stating > that there are no IANA registries defined. it shoudl also state how the protocol gets extended - e.g., it gets extended only thorugh IETF standards action - to keep other stds orgs from thinking they can extend it on their own Scott _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 26 11:01:17 2002 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 LAA07815 for ; Tue, 26 Nov 2002 11:01:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQG3X703094 for midcom-archive@odin.ietf.org; Tue, 26 Nov 2002 11:03:33 -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 gAQFxYv02865; Tue, 26 Nov 2002 10:59:34 -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 gAQFufv02700 for ; Tue, 26 Nov 2002 10:56:41 -0500 Received: from EXECDSL.COM (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07395 for ; Tue, 26 Nov 2002 10:53:54 -0500 (EST) Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 3994829; Tue, 26 Nov 2002 10:56:37 -0500 Message-Id: <5.1.0.14.0.20021126105141.01864540@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Nov 2002 10:56:22 -0500 To: Martin Stiemerling From: "Joel M. Halpern" Subject: Re: [midcom] Midcom proposal: please read Cc: midcom@ietf.org In-Reply-To: <3DE35695.1010706@ccrle.nec.de> References: <200211251342.AAY06880@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , It is a reasonable question. THe semantics of SNMP are defined such that if a single PDU has multiple SETs, then they MUST be done atomically. That is, either all of them are done or none of them are done. Thus, semantically, this is a match for what MIDCOM requires. It is worth noting that the realities of protocols make this a less than perfect match. The SNMP requirement applies to the requests in a single message. Currently, that is a single UDP datagram. Since we do not want to put in a dependence on the forthcoming SNMP over TCP, this does limit the scope of atomicity. I believe the limitation is acceptable, but it is as far as I know a real limit. (There are those who would argue that IP Fragmentation would allow a larger UDP datagram. Bad answer.) Yours, Joel M. Halpern PS: THis particular aspect of SNMP semantics is part of SNMPv1 as well as v3. At 12:10 PM 11/26/2002 +0100, Martin Stiemerling wrote: >I have a question regarding SNMP and setting multiple values at the same >time. Perhaps this is a very basic question, but I see some problems here. > >For MIDCOM it is required to configure all data of the policy rule at the >same time and to get the data really configured (all or nothing >principle). In SNMP you can set one value and check wether this has been >set properly or not. What about SNMP if you have to set 5-tuples at the >same time. Is there any mechanism in the SNMP protocol that allow this or >do we have to create our own mechanism? > >A word ahead: I would appreciate detailed answers and not just plain >answers like "It works because it is defined", since I'm not aware about >all geat features in SNMPv3. > >Martin > > >Melinda Shore wrote: > >>There was a proposal made during the midcom session at the >>IETF meeting to shortcut the protocol selection process and >>just go with SNMPv3 as the midcom protocol. Consistent with >>IETF process, this is a decision to be made on the mailing >>list. I'd like to come to a decision within the next week >>or so (Thursday is Thanksgiving in the US and many people >>may be away this week). >>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 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Nov 26 12:08:10 2002 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 MAA11198 for ; Tue, 26 Nov 2002 12:08:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQHARX09926 for midcom-archive@odin.ietf.org; Tue, 26 Nov 2002 12:10:27 -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 gAQH9ov09891; Tue, 26 Nov 2002 12:09:50 -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 gAQH1Uv08474 for ; Tue, 26 Nov 2002 12:01:30 -0500 Received: from smtp016.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10835 for ; Tue, 26 Nov 2002 11:58:42 -0500 (EST) Received: from 207-172-130-132.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com (HELO jpmetower) (jmoisand@207.172.130.132 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 26 Nov 2002 17:01:24 -0000 Message-ID: <000601c2956d$727158c0$8482accf@cable.rcn.com> From: "Jerome Moisand" To: "Melinda Shore" Cc: References: <200211251342.AAY06880@mira-sjc5-4.cisco.com> <3DE35695.1010706@ccrle.nec.de> Subject: Re: [midcom] Midcom proposal: please read Date: Tue, 26 Nov 2002 12:01:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 Hello, I'm new to this list, so apologies in advance if I might repeat what other people already stated. If I remember well, the main point made during the midcom session about shorcutting the protocol selection process was that SNMP is way more widely implemented than other protocol candidates. I am not sure to see the value of this point. First, SNMP is definitely widely implemented, but essentially for monitoring purposes (alarms & stats). It seems a big stretch to say that SNMP is widely implemented for provisioning & for authorization, where protocols like CLI and Radius are by far the most widely deployed. Also SNMPv1 and to a lesser extent SNMPv2 are widely used, but it also seems a big stretch to say that SNMPv3 is widely implemented. Just look at the largest router manufacturer general strategy in this respect... Second, the fact that a protocol is widely implemented doesn't make it suitable for all purposes. Both Diameter and COPS have been designed to allow better processing for transaction-oriented policy decisions (which is exactly what midcom is about, I believe). Both protocols were intended to address such situations that SNMP and Radius were not good at. If it were not the case, why did IETF spend so much time working on these two new protocols? Also note that the mere fact that these protocols have been recently defined makes it obvious that they are not yet widely implemented. So? Should we never use next-gen protocols on this basis? I don't believe so. Bottomline: I wouldn't understand why such a "decision shortcut" would be used on the basis of this "wide implementation" argument, which doesn't seem (to me) to hold much water. I believe the "midcom" group needs to find a better rationale (and process) for making such decision. Tx Jerome Moisand (Juniper Networks) > Melinda Shore wrote: > > > There was a proposal made during the midcom session at the > > IETF meeting to shortcut the protocol selection process and > > just go with SNMPv3 as the midcom protocol. Consistent with > > IETF process, this is a decision to be made on the mailing > > list. I'd like to come to a decision within the next week > > or so (Thursday is Thanksgiving in the US and many people > > may be away this week). > > > > 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 Nov 27 09:43:23 2002 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 JAA12238 for ; Wed, 27 Nov 2002 09:43:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAREjcs30741 for midcom-archive@odin.ietf.org; Wed, 27 Nov 2002 09:45: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 gAREj7v30677; Wed, 27 Nov 2002 09:45: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 gAREX4v29542 for ; Wed, 27 Nov 2002 09:33:04 -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 JAA11514 for ; Wed, 27 Nov 2002 09:30:17 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAREWmY36523; Wed, 27 Nov 2002 15:32:48 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0, from userid 30) id B2F947B67E; Wed, 27 Nov 2002 15:31:08 +0100 (CET) Cc: midcom@ietf.org, "Melinda Shore" X-Accept-Language: de, en X-Priority: 3 (Normal) X-Mailer: SKYRiXgreen_3.1 NGMime_4.2.18 references: <200211251342.AAY06880@mira-sjc5-4.cisco.com> <3DE35695.1010706@ccrle.nec.de> <000601c2956d$727158c0$8482accf@cable.rcn.com> From: "Juergen Quittek" MIME-Version: 1.0 subject: Re: [midcom] Midcom proposal: please read To: "Jerome Moisand" content-type: text/plain; charset="iso-8859-1" date: Wed, 27 Nov 2002 15:31:08 +0100 content-transfer-encoding: 7bit Message-Id: <20021127143108.B2F947B67E@imap.heidelberg.ccrle.nec.de> 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 Jerome, I am also not sure whether or not SNMP would be a good choice for MIDCOM. But your arguments confused me. Do you want to say "everything else would be better? Or do you see a good candidate, you would prefer? Please see some more comments inline. Juergen > Hello, > > I'm new to this list, so apologies in advance if I might repeat what other > people already stated. > > If I remember well, the main point made during the midcom session about > shorcutting the protocol selection process was that SNMP is way more widely > implemented than other protocol candidates. > > I am not sure to see the value of this point. > > First, SNMP is definitely widely implemented, but essentially for monitoring > purposes (alarms & stats). It seems a big stretch to say that SNMP is widely > implemented for provisioning & for authorization, where protocols like CLI Yes, CLI is really most widely implemented as configuration protocol. But this is not at all a protocol (maybe it is 1000 protocols :-). > and Radius are by far the most widely deployed. Also SNMPv1 and to a lesser > extent SNMPv2 are widely used, but it also seems a big stretch to say that > SNMPv3 is widely implemented. Just look at the largest router manufacturer > general strategy in this respect... > > Second, the fact that a protocol is widely implemented doesn't make it > suitable for all purposes. Both Diameter and COPS have been designed to First you compare SNMPv3 to CLI and say its much less widely used. This is completely right, but not useful at all. Now you compare it to COPS and Diameter. Compared to Diameter (and probably also COPS), SNMPv3 is indeed widely used. > allow better processing for transaction-oriented policy decisions (which is > exactly what midcom is about, I believe). Both protocols were intended to > address such situations that SNMP and Radius were not good at. If it were Please exlain! How is COPS addressing the "mutliple clients configuring a single server while addressing the same (kind of) resources)" situation? I would say: not at all. > not the case, why did IETF spend so much time working on these two new > protocols? Also note that the mere fact that these protocols have been > recently defined makes it obvious that they are not yet widely implemented. > So? Should we never use next-gen protocols on this basis? I don't believe > so. I cannot follow your argument. We are using a lot of very recent protocols, but do we have to choose them always, just because the are new? If COPS-PR is not even widely used in it's original domain, policy-based configuration, yet, then why should I already consider using it for other purposes for which it was not really designed. The situation would certainly be different, if COPS was already implemented widely for policy-based configuration of devices. But since it is not (and I personally see it coming soon, why should I choose it? Because it is 'next-gen'? > > Bottomline: I wouldn't understand why such a "decision shortcut" would be > used on the basis of this "wide implementation" argument, which doesn't seem > (to me) to hold much water. I believe the "midcom" group needs to find a > better rationale (and process) for making such decision. On this point, I fully agree with you! > > Tx > Jerome Moisand (Juniper Networks) > > > Melinda Shore wrote: > > > > > There was a proposal made during the midcom session at the > > > IETF meeting to shortcut the protocol selection process and > > > just go with SNMPv3 as the midcom protocol. Consistent with > > > IETF process, this is a decision to be made on the mailing > > > list. I'd like to come to a decision within the next week > > > or so (Thursday is Thanksgiving in the US and many people > > > may be away this week). > > > > > > 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 > -- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Nov 27 09:47:06 2002 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 JAA12545 for ; Wed, 27 Nov 2002 09:47:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAREnM530967 for midcom-archive@odin.ietf.org; Wed, 27 Nov 2002 09:49:22 -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 gAREn2v30950; Wed, 27 Nov 2002 09:49:02 -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 gAREmZv30915 for ; Wed, 27 Nov 2002 09:48:35 -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 JAA12404 for ; Wed, 27 Nov 2002 09:45:48 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAREmHY37813; Wed, 27 Nov 2002 15:48:17 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0, from userid 30) id BA1D17B6AF; Wed, 27 Nov 2002 15:46:38 +0100 (CET) Cc: midcom@ietf.org, "Melinda Shore" X-Accept-Language: de, en X-Priority: 3 (Normal) X-Mailer: SKYRiXgreen_3.1 NGMime_4.2.18 references: <200211251516.AAY08340@mira-sjc5-4.cisco.com> <3DE3553A.7020804@ccrle.nec.de> From: "Juergen Quittek" MIME-Version: 1.0 subject: Re: [midcom] IETF 55 minutes To: "Martin Stiemerling" content-type: text/plain; charset="iso-8859-1" date: Wed, 27 Nov 2002 15:46:38 +0100 Message-Id: <20021127144638.BA1D17B6AF@imap.heidelberg.ccrle.nec.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAREmZv30916 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 have just done a quick look through the minutes w.r.t.the semantics. > My memories are different from some issues written below. Further > comments are inline and thanks to Bob for writing down the minutes > > Kind Regards > Martin > > > ============================================================== > > Midcom protocol semantics - draft-ietf-midcom-semantics-00.txt > > -------------------------------------------------------------- > > Juergen Quittek presented the Semantics document issues. > > > Juergen Quittek didn't present the semantics. Furthermore the semantics > doc was a combined work of Jürgen, Tom and Martin and presented by Martin. Martin, maybe we look to similar :-) In Yokohama I made some comments and the minutes stated "Martin said ...". Now you made a presentation and the minutes draft says "Juergen presented" ... maybe it's just a compensation ;-) Juergen > > > > > > - There is now one combined semantics document. > > > > - There is one transaction set for Firewall and NAT. > > > > - Works on first-come, first-served basis. > > > > - Goal is to keep the semantics simple & stupid. > > > > - Why PRR? Need to do the binding to complete the 5-tuple in order > > for agent to pass on signaling message. Is Twice-NAT required? > > > The question was wether the return values should reflect the presence of > a twice-NAT or not. > > > > > > - Group Transactions have been removed. Group creation is now implicit > > in PRR and PER transactions. > > > Group transactions have not been removed and group creation is currently > not implicit. This was a question if we should remove the Group > establishment transaction or not. I think that there has been no > consensus during the meeting to change anyhting in the semantics. The > decissions have been moved to the list. > > > > > > - Wildcarding needs list discussion > > > OK. > > > > > > - Return Values: Should full 5-tuple be included in response so > > that FW/NAT function is transparent to the agent? > > > > - Should PER be split into two requests? > > > > - Message Queuing. Transactions need to be atomic and operate on > > first come first served basis. > > > > May be it is better to write this a question, since there was no > consensus on this. > > > > > > - Capabilities exchange: is list in spec complete? > > > > - Encryption Method - It was pointed out that the encryption method and > > keying needs to be decoupled. Issue needs list discussion. > > > > It was reported that the NSIS WG had discussed using CASP and TIST to talk > > to FW/NATs. > > > > > > _______________________________________________ > 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 Nov 27 09:57:43 2002 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 JAA13132 for ; Wed, 27 Nov 2002 09:57:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARExxv31515 for midcom-archive@odin.ietf.org; Wed, 27 Nov 2002 09:59:59 -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 gARExVv31500; Wed, 27 Nov 2002 09:59: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 gAREw7v31449 for ; Wed, 27 Nov 2002 09:58:07 -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 JAA13037 for ; Wed, 27 Nov 2002 09:55:21 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAREw4Y38397; Wed, 27 Nov 2002 15:58:04 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0, from userid 30) id EEC297B6D0; Wed, 27 Nov 2002 15:56:24 +0100 (CET) Cc: midcom@ietf.org, "Martin Stiemerling" X-Accept-Language: de, en X-Priority: 3 (Normal) X-Mailer: SKYRiXgreen_3.1 NGMime_4.2.18 references: <200211251342.AAY06880@mira-sjc5-4.cisco.com> <5.1.0.14.0.20021126105141.01864540@mail.stevecrocker.com> From: "Juergen Quittek" MIME-Version: 1.0 subject: Re: [midcom] Midcom proposal: please read To: "Joel M. Halpern" content-type: text/plain; charset="iso-8859-1" date: Wed, 27 Nov 2002 15:56:24 +0100 content-transfer-encoding: 7bit Message-Id: <20021127145624.EEC297B6D0@imap.heidelberg.ccrle.nec.de> 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 Joel, > It is a reasonable question. > > THe semantics of SNMP are defined such that if a single PDU has multiple > SETs, then they MUST be done atomically. That is, either all of them are > done or none of them are done. > Thus, semantically, this is a match for what MIDCOM requires. I think for most MIDCOM transactions it would not be a problem to fit all parameters into a single PDU. But the SNMP spec saying that the order in which the sets are executed is not deterministic, makes it hard to 1. create a row for a new policy, 2. fill all objects of the row, and 3. set the row to be active (or enabled) with a single PDU. Rather, I think three PDUs are required for this. However, you can still provide atomicity, by having not impact at all on the middlebox behavior after step 1 and 2 and then enabling the policy int the atomic step 3. You can even add to the semantics of step 3 that the entire row will be deleted, if step 3 fails. Juergen > It is worth noting that the realities of protocols make this a less than > perfect match. The SNMP requirement applies to the requests in a single > message. Currently, that is a single UDP datagram. Since we do not want > to put in a dependence on the forthcoming SNMP over TCP, this does limit > the scope of atomicity. I believe the limitation is acceptable, but it is > as far as I know a real limit. (There are those who would argue that IP > Fragmentation would allow a larger UDP datagram. Bad answer.) > > Yours, > Joel M. Halpern > > PS: THis particular aspect of SNMP semantics is part of SNMPv1 as well as v3. > > At 12:10 PM 11/26/2002 +0100, Martin Stiemerling wrote: > >I have a question regarding SNMP and setting multiple values at the same > >time. Perhaps this is a very basic question, but I see some problems here. > > > >For MIDCOM it is required to configure all data of the policy rule at the > >same time and to get the data really configured (all or nothing > >principle). In SNMP you can set one value and check wether this has been > >set properly or not. What about SNMP if you have to set 5-tuples at the > >same time. Is there any mechanism in the SNMP protocol that allow this or > >do we have to create our own mechanism? > > > >A word ahead: I would appreciate detailed answers and not just plain > >answers like "It works because it is defined", since I'm not aware about > >all geat features in SNMPv3. > > > >Martin > > > > > >Melinda Shore wrote: > > > >>There was a proposal made during the midcom session at the > >>IETF meeting to shortcut the protocol selection process and > >>just go with SNMPv3 as the midcom protocol. Consistent with > >>IETF process, this is a decision to be made on the mailing > >>list. I'd like to come to a decision within the next week > >>or so (Thursday is Thanksgiving in the US and many people > >>may be away this week). > >>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 > > > _______________________________________________ > 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 Nov 27 10:16:12 2002 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 KAA13966 for ; Wed, 27 Nov 2002 10:16:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARFIS100526 for midcom-archive@odin.ietf.org; Wed, 27 Nov 2002 10:18: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 gARFI7v00483; Wed, 27 Nov 2002 10:18: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 gARFHCv00426 for ; Wed, 27 Nov 2002 10:17:12 -0500 Received: from smtp015.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13901 for ; Wed, 27 Nov 2002 10:14:25 -0500 (EST) Received: from 207-172-130-132.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com (HELO jpmetower) (jmoisand@207.172.130.132 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 27 Nov 2002 15:17:03 -0000 Message-ID: <001001c29628$08d796c0$8482accf@cable.rcn.com> From: "Jerome Moisand" To: References: <200211251342.AAY06880@mira-sjc5-4.cisco.com> <3DE35695.1010706@ccrle.nec.de> <000601c2956d$727158c0$8482accf@cable.rcn.com> <20021127143108.B2F947B67E@imap.heidelberg.ccrle.nec.de> Subject: Re: [midcom] Midcom proposal: please read Date: Wed, 27 Nov 2002 10:16: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 Juergen, I was just saying that choosing SNMPv3 because it's "widely deployed" isn't a convincing argument at all. I was not making a case for choosing this protocol or against it, I do see multiple Pros & Cons for SNMPv3 (and the others). I just wanted to express the opinion that we shouldn't shortcut the decision-making process. (see below a few more details for clarification, but not really adding much to my points). Tx Jerome ----- Original Message ----- From: "Juergen Quittek" To: "Jerome Moisand" Cc: ; "Melinda Shore" Sent: Wednesday, November 27, 2002 9:31 AM Subject: Re: [midcom] Midcom proposal: please read > Hi Jerome, > > I am also not sure whether or not SNMP would be a good choice for > MIDCOM. But your arguments confused me. Do you want to say "everything > else would be better? Or do you see a good candidate, you would > prefer? > > Please see some more comments inline. => and my answers > > Juergen > > > Hello, > > > > I'm new to this list, so apologies in advance if I might repeat what other > > people already stated. > > > > If I remember well, the main point made during the midcom session about > > shorcutting the protocol selection process was that SNMP is way more widely > > implemented than other protocol candidates. > > > > I am not sure to see the value of this point. > > > > First, SNMP is definitely widely implemented, but essentially for monitoring > > purposes (alarms & stats). It seems a big stretch to say that SNMP is widely > > implemented for provisioning & for authorization, where protocols like CLI > > Yes, CLI is really most widely implemented as configuration protocol. > But this is not at all a protocol (maybe it is 1000 protocols :-). => I facetiously referred to CLI as a protocol, knowing well that many people will balk at this terminology! ;-) => Yes, we're in complete agreement here. > > and Radius are by far the most widely deployed. Also SNMPv1 and to a lesser > > extent SNMPv2 are widely used, but it also seems a big stretch to say that > > SNMPv3 is widely implemented. Just look at the largest router manufacturer > > general strategy in this respect... > > > > Second, the fact that a protocol is widely implemented doesn't make it > > suitable for all purposes. Both Diameter and COPS have been designed to > > First you compare SNMPv3 to CLI and say its much less widely used. This > is completely right, but not useful at all. Now you compare it to COPS > and Diameter. Compared to Diameter (and probably also COPS), SNMPv3 is > indeed widely used. => everything is relative, but all in all, none of the proposed candidates (SNMPv3 for provisioning, Diameter, COPS) is widely used yet, far from it. By either Network Elements, or OSS systems. Or let's say, not to a point where it should become a significant factor in our decision-making. These three protocols clearly remain to be proven on the field. This is only my perception, of course (probably tainted by the fact that I know well Service Providers environments, but less enterprise networking). > > allow better processing for transaction-oriented policy decisions (which is > > exactly what midcom is about, I believe). Both protocols were intended to > > address such situations that SNMP and Radius were not good at. If it were > > Please exlain! How is COPS addressing the "mutliple clients configuring > a single server while addressing the same (kind of) resources)" situation? > I would say: not at all. => this is another thread of discussion. I did hear Melinda express reservations on this point, but this deserves a separate e-mail thread. I'll come back on this, as well as the transaction aspect of midcom (where I think SNMPv3 has a big issue). => maybe somebody would be kind enough to copy & paste some previous e-mail thread on this topic, and forward it to me? Just to not making you guys repeat yourselves? > > not the case, why did IETF spend so much time working on these two new > > protocols? Also note that the mere fact that these protocols have been > > recently defined makes it obvious that they are not yet widely implemented. > > So? Should we never use next-gen protocols on this basis? I don't believe > > so. > > I cannot follow your argument. We are using a lot of very recent protocols, > but do we have to choose them always, just because the are new? If COPS-PR > is not even widely used in it's original domain, policy-based configuration, > yet, then why should I already consider using it for other purposes for which > it was not really designed. The situation would certainly be different, if > COPS was already implemented widely for policy-based configuration of devices. > But since it is not (and I personally see it coming soon, why should I choose > it? Because it is 'next-gen'? => funny the way you took the direct negation of my statement! You're saying we should NOT *always* use recent protocols just because they are recent. I was just saying that we should NOT *always* use old protocols (or new flavors of an old protocol) just because they are 'old' (hence 'proven') and have been widely used for a completly different application (e.g. monitoring). Well, both statements are fair, I believe! => maybe I don't fully understand yet what midcom is about, but I do see this as a dynamic policy management problem with transactional properties. So it only seems natural to look at policy management protocols. Which the group rightfully did, without jumping to hasty conclusions. All this sounds fair to me. But suddenly shortcutting such process based on a very debatable point, that, I have to disagree with. > > > > Bottomline: I wouldn't understand why such a "decision shortcut" would be > > used on the basis of this "wide implementation" argument, which doesn't seem > > (to me) to hold much water. I believe the "midcom" group needs to find a > > better rationale (and process) for making such decision. > > On this point, I fully agree with you! => hey, we did agree on a couple of things, great! ;-) > > > > Tx > > Jerome Moisand (Juniper Networks) > > > > > Melinda Shore wrote: > > > > > > > There was a proposal made during the midcom session at the > > > > IETF meeting to shortcut the protocol selection process and > > > > just go with SNMPv3 as the midcom protocol. Consistent with > > > > IETF process, this is a decision to be made on the mailing > > > > list. I'd like to come to a decision within the next week > > > > or so (Thursday is Thanksgiving in the US and many people > > > > may be away this week). > > > > > > > > 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 > > > -- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Nov 27 10:39:32 2002 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 KAA15138 for ; Wed, 27 Nov 2002 10:39:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARFfmS02301 for midcom-archive@odin.ietf.org; Wed, 27 Nov 2002 10:41: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 gARFfEv02262; Wed, 27 Nov 2002 10:41:14 -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 gARFeXv02200 for ; Wed, 27 Nov 2002 10:40:33 -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 KAA15058 for ; Wed, 27 Nov 2002 10:37:46 -0500 (EST) Received: from 207-172-130-132.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com (HELO jpmetower) (jmoisand@207.172.130.132 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 27 Nov 2002 15:40:29 -0000 Message-ID: <002501c2962b$4ee6bda0$8482accf@cable.rcn.com> From: "Jerome Moisand" To: Date: Wed, 27 Nov 2002 10:40:25 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C29601.65581400" 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 Subject: [midcom] clarification requested on middlebox concept Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C29601.65581400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry, guys, still trying to catch up.... Help welcome. The middlecom charter says: << As trusted third parties are increasingly being asked to make policy = decisions on behalf of the various entities participating in an = application's operation, a need has developed for applications to be = able to communicate their needs to the devices in the network that = provide transport policy enforcement. Examples of these devices include = firewalls, network address translators (both within and between address = families), signature management for intrusion detection systems, and = multimedia buffer management. These devices are a subset of what can be = referred to as 'middleboxes.'=20 This working group will focus its attention on communication with = firewalls and network address translators (including translation between = IPv6 and IPv4). Work will not preclude extensibility to other categories = of middle box.=20 >> Well, it seems to me that edge routers (where service & subscriber = management is typically enforced) are a very good fit for this = 'middlebox' definition. That is, for a service provider environment of = course. I've participated to multiple discussions about multimedia flows (VoIP, = video, whatever) in various contexts (DSL, Cable, Metro-Eth, GPRS, etc), = and I did hear Service providers express a clear desire to control such = sessions on an individual basis (filtering unwanted traffic -all voice = calls will get charged!-, doing session-based admission control to = guarantee the level of service, enforcing differentiated QoS levels = depending on the type of flow but also on the subscriber subscriptions, = etc). Some think that functions like NAT or Firewalling may also belong to = such 'edge router' space, some do not.=20 In any case, it seems to me that we should keep in mind a bigger picture = where such 'midcom' transaction (say triggered by a SIP proxy of some = sort, or a Video app server, etc) would not only act in the NAT/FW side = of things, but also on the QoS side of things. Sure, in such a larger picture, some may argue that the RSVP scheme from = a CPE device is the way to go. Personally, I'm not sure to agree with = such view, but in any case, I don't see a fundamental difference between = poking per-session holes in a NAT/FW for a multimedia session, or = working with filters and attach a QoS profile to an edge router = subscriber interface. And the midcom control protocol design should then = be similar. Ok, so please, don't flame me on the RSVP comments, I JUST would like to = understand if I properly understood the 'middlebox' concept and if a = service/subscriber-oriented edge router qualifies. Tx Jerome PS. going down this "multimedia control" route also begs the question of = why MGCP/Megaco was not considered as a possible 'midcom' protocol = candidate? Don't misread me, I'm not saying this is the right choice, = just asking questions to better understand the history of the = discussion. ------=_NextPart_000_0022_01C29601.65581400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sorry, guys, still trying to catch = up.... Help=20 welcome.
 
The middlecom charter = says:
<<
As trusted=20 third parties are increasingly being asked to make policy decisions on = behalf of=20 the various entities participating in an application's operation, a need = has=20 developed for applications to be able to communicate their needs to the = devices=20 in the network that provide transport policy enforcement. Examples of = these=20 devices include firewalls, network address translators (both within and = between=20 address families), signature management for intrusion detection systems, = and=20 multimedia buffer management. These devices are a subset of what can be = referred=20 to as 'middleboxes.'

This working group will focus its attention on communication with = firewalls=20 and network address translators (including translation between IPv6 and = IPv4).=20 Work will not preclude extensibility to other categories of middle box. =

>>

Well, it seems to me that edge routers (where service & = subscriber=20 management is typically enforced) are a very good fit for this = 'middlebox'=20 definition. That is, for a service provider environment of course.

I've participated to multiple discussions about multimedia flows = (VoIP,=20 video, whatever) in various contexts (DSL, Cable, Metro-Eth, GPRS, etc), = and I=20 did hear Service providers express a clear desire to control such = sessions on an=20 individual basis (filtering unwanted traffic -all voice calls will get=20 charged!-, doing session-based admission control to guarantee the level = of=20 service, enforcing differentiated QoS levels depending on the type of = flow but=20 also on the subscriber subscriptions, etc).

Some think that functions like NAT or Firewalling may also = belong to=20 such 'edge router' space, some do not.

In any case, it seems to me that we should keep in mind a bigger = picture=20 where such 'midcom' transaction (say triggered by a SIP proxy of some = sort, or a=20 Video app server, etc) would not only act in the NAT/FW side of things, = but also=20 on the QoS side of things.

Sure, in such a larger picture, some may argue that the RSVP scheme = from a=20 CPE device is the way to go. Personally, I'm not sure to agree with such = view,=20 but in any case, I don't see a fundamental difference between poking = per-session=20 holes in a NAT/FW for a multimedia session, or working with=20 filters and attach a QoS profile to an edge router subscriber = interface.=20 And the midcom control protocol design should then be similar.

Ok, so please, don't flame me on the RSVP comments, I JUST would like = to=20 understand if I properly understood the 'middlebox' concept and if a=20 service/subscriber-oriented edge router qualifies.

Tx

Jerome

PS. going down this "multimedia control" route also begs the question = of why=20 MGCP/Megaco was not considered as a possible 'midcom' protocol = candidate? Don't=20 misread me, I'm not saying this is the right choice, just asking = questions to=20 better understand the history of the discussion.

 

 

 ------=_NextPart_000_0022_01C29601.65581400-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Nov 27 10:50:23 2002 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 KAA15768 for ; Wed, 27 Nov 2002 10:50:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARFqeL02848 for midcom-archive@odin.ietf.org; Wed, 27 Nov 2002 10:52:40 -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 gARFqAv02808; Wed, 27 Nov 2002 10:52:10 -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 gARFpYv02719 for ; Wed, 27 Nov 2002 10:51:34 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15648 for ; Wed, 27 Nov 2002 10:48:47 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gARFpUcb004610; Wed, 27 Nov 2002 07:51:30 -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 ABA24192; Wed, 27 Nov 2002 07:51:29 -0800 (PST) Message-Id: <200211271551.ABA24192@mira-sjc5-c.cisco.com> To: "Jerome Moisand" cc: midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] clarification requested on middlebox concept In-Reply-To: Message from "Jerome Moisand" of "Wed, 27 Nov 2002 10:40:25 EST." <002501c2962b$4ee6bda0$8482accf@cable.rcn.com> Date: Wed, 27 Nov 2002 10:51:29 -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: , > In any case, it seems to me that we should keep in mind a bigger picture = > where such 'midcom' transaction (say triggered by a SIP proxy of some = > sort, or a Video app server, etc) would not only act in the NAT/FW side = > of things, but also on the QoS side of things. QoS is specifically out of scope. > Sure, in such a larger picture, some may argue that the RSVP scheme from = > a CPE device is the way to go. The NSIS working group is discussing an RSVP-like protocol that will be used for QoS signaling and also middlebox communication. > PS. going down this "multimedia control" route also begs the question of = > why MGCP/Megaco was not considered as a possible 'midcom' protocol = > candidate? It is still in the running - please read draft-ietf-midcom- protocol-eval-06.txt. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Nov 27 10:58:32 2002 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 KAA16163 for ; Wed, 27 Nov 2002 10:58:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARG0n503262 for midcom-archive@odin.ietf.org; Wed, 27 Nov 2002 11:00: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 gARG0Ov03249; Wed, 27 Nov 2002 11:00:24 -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 gARFuQv03076 for ; Wed, 27 Nov 2002 10:56:26 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15935 for ; Wed, 27 Nov 2002 10:53:39 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gARFuH0R022737; Wed, 27 Nov 2002 07:56:17 -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 ABA24357; Wed, 27 Nov 2002 07:56:20 -0800 (PST) Message-Id: <200211271556.ABA24357@mira-sjc5-c.cisco.com> To: "Jerome Moisand" cc: midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Midcom proposal: please read In-Reply-To: Message from "Jerome Moisand" of "Wed, 27 Nov 2002 10:16:59 EST." <001001c29628$08d796c0$8482accf@cable.rcn.com> Date: Wed, 27 Nov 2002 10:56:20 -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: , > I just wanted to express the opinion that we shouldn't shortcut the > decision-making process. To the contrary - the scores among the various protocols as presented in the evaluation document are very close, and if there are intangibles that were not possible to quantify that allow us to short-cut a protracted and likely unproductive discussion, by all means we should do so. Obviously if there is non-trivial dissent we won't forge on ahead with SNMPv3 without more fully considering the other candidates. We aren't there yet. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Nov 27 11:37:22 2002 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 LAA18022 for ; Wed, 27 Nov 2002 11:37:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARGdc106865 for midcom-archive@odin.ietf.org; Wed, 27 Nov 2002 11:39: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 gARGdHv06855; Wed, 27 Nov 2002 11:39: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 gARGcuv06780 for ; Wed, 27 Nov 2002 11:38:56 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17925 for ; Wed, 27 Nov 2002 11:36:08 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gARGcqcb000506; Wed, 27 Nov 2002 08:38:52 -0800 (PST) Received: from CJ650 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id DFP00355; Wed, 27 Nov 2002 08:39:12 -0800 (PST) From: "Cullen Jennings" To: "Jerome Moisand" , Subject: RE: [midcom] Midcom proposal: please read Date: Wed, 27 Nov 2002 08:40:00 -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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <000601c2956d$727158c0$8482accf@cable.rcn.com> 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 Agreeing with Jerome ... SNMP may be right but I don't see it as dead obvious right now so I think we should look carefully at the options - and we need to look at how much we will need to change the option to make it work. TCP is widely implemented and we could send things with lots of <> brackets over it. Question is, how much effort will it be to get any of these options implemented, doing the right thing, and widely deployed. From the discussion so far, it is not clear to me that any proposal is a clear winner over the others. Cullen > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Jerome Moisand > Sent: Tuesday, November 26, 2002 9:01 AM > To: Melinda Shore > Cc: midcom@ietf.org > Subject: Re: [midcom] Midcom proposal: please read > > > Hello, > > I'm new to this list, so apologies in advance if I might repeat what other > people already stated. > > If I remember well, the main point made during the midcom session about > shorcutting the protocol selection process was that SNMP is way > more widely > implemented than other protocol candidates. > > I am not sure to see the value of this point. > > First, SNMP is definitely widely implemented, but essentially for > monitoring > purposes (alarms & stats). It seems a big stretch to say that > SNMP is widely > implemented for provisioning & for authorization, where protocols like CLI > and Radius are by far the most widely deployed. Also SNMPv1 and > to a lesser > extent SNMPv2 are widely used, but it also seems a big stretch to say that > SNMPv3 is widely implemented. Just look at the largest router manufacturer > general strategy in this respect... > > Second, the fact that a protocol is widely implemented doesn't make it > suitable for all purposes. Both Diameter and COPS have been designed to > allow better processing for transaction-oriented policy decisions > (which is > exactly what midcom is about, I believe). Both protocols were intended to > address such situations that SNMP and Radius were not good at. If it were > not the case, why did IETF spend so much time working on these two new > protocols? Also note that the mere fact that these protocols have been > recently defined makes it obvious that they are not yet widely > implemented. > So? Should we never use next-gen protocols on this basis? I don't believe > so. > > Bottomline: I wouldn't understand why such a "decision shortcut" would be > used on the basis of this "wide implementation" argument, which > doesn't seem > (to me) to hold much water. I believe the "midcom" group needs to find a > better rationale (and process) for making such decision. > > Tx > Jerome Moisand (Juniper Networks) > > > Melinda Shore wrote: > > > > > There was a proposal made during the midcom session at the > > > IETF meeting to shortcut the protocol selection process and > > > just go with SNMPv3 as the midcom protocol. Consistent with > > > IETF process, this is a decision to be made on the mailing > > > list. I'd like to come to a decision within the next week > > > or so (Thursday is Thanksgiving in the US and many people > > > may be away this week). > > > > > > 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 > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Nov 27 11:41:26 2002 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 LAA18150 for ; Wed, 27 Nov 2002 11:41:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARGhhw07106 for midcom-archive@odin.ietf.org; Wed, 27 Nov 2002 11:43:43 -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 gARGe2v06916; Wed, 27 Nov 2002 11:40:02 -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 gARGd3v06830 for ; Wed, 27 Nov 2002 11:39:03 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17934 for ; Wed, 27 Nov 2002 11:36:15 -0500 (EST) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gARGcrcb000516; Wed, 27 Nov 2002 08:38:53 -0800 (PST) Received: from CJ650 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id DFP00357; Wed, 27 Nov 2002 08:39:13 -0800 (PST) From: "Cullen Jennings" To: "Jonathan Rosenberg" Cc: Subject: RE: [midcom] STUN issue #7: recommended stateless server procedures Date: Wed, 27 Nov 2002 08:40:01 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: 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 Did our esteemed colleague, Mr. Bellovin, provide any insight on purpose of the prefix? _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Nov 27 11:51:32 2002 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 LAA18779 for ; Wed, 27 Nov 2002 11:51:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARGrnN07795 for midcom-archive@odin.ietf.org; Wed, 27 Nov 2002 11:53: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 gARGrJv07761; Wed, 27 Nov 2002 11:53:19 -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 gARGqvv07715 for ; Wed, 27 Nov 2002 11:52:57 -0500 Received: from acmepacket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18738 for ; Wed, 27 Nov 2002 11:50:09 -0500 (EST) Received: from BPenfield [127.0.0.1] by acmepacket.com (SMTPD32-7.07) id A861EB420140; Wed, 27 Nov 2002 11:52:49 -0500 Message-ID: <008201c29635$63b98190$2300000a@BPenfield> From: "Bob Penfield" To: "Martin Stiemerling" , "Juergen Quittek" Cc: "midcom" , "Melinda Shore" References: <200211251516.AAY08340@mira-sjc5-4.cisco.com> <3DE3553A.7020804@ccrle.nec.de> <20021127144638.BA1D17B6AF@imap.heidelberg.ccrle.nec.de> Subject: Re: [midcom] IETF 55 minutes Date: Wed, 27 Nov 2002 11:52:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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: 8bit 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 apologize for my faulty memory. Somehow I neglected to write down that it was Martin and the posted agenda did not list presenters. ----- Original Message ----- From: "Juergen Quittek" To: "Martin Stiemerling" Cc: ; "Melinda Shore" Sent: Wednesday, November 27, 2002 9:46 AM Subject: Re: [midcom] IETF 55 minutes > > I have just done a quick look through the minutes w.r.t.the semantics. > > My memories are different from some issues written below. Further > > comments are inline and thanks to Bob for writing down the minutes > > > > Kind Regards > > Martin > > > > > ============================================================== > > > Midcom protocol semantics - draft-ietf-midcom-semantics-00.txt > > > -------------------------------------------------------------- > > > Juergen Quittek presented the Semantics document issues. > > > > > > Juergen Quittek didn't present the semantics. Furthermore the semantics > > doc was a combined work of Jürgen, Tom and Martin and presented by Martin. > > Martin, maybe we look to similar :-) In Yokohama I made some comments and > the minutes stated "Martin said ...". Now you made a presentation and > the minutes draft says "Juergen presented" ... maybe it's just a > compensation ;-) > > Juergen > > > > > > > > > > > - There is now one combined semantics document. > > > > > > - There is one transaction set for Firewall and NAT. > > > > > > - Works on first-come, first-served basis. > > > > > > - Goal is to keep the semantics simple & stupid. > > > > > > - Why PRR? Need to do the binding to complete the 5-tuple in order > > > for agent to pass on signaling message. Is Twice-NAT required? > > > > > > The question was wether the return values should reflect the presence of > > a twice-NAT or not. > > > > > > > > > > - Group Transactions have been removed. Group creation is now implicit > > > in PRR and PER transactions. > > > > > > Group transactions have not been removed and group creation is currently > > not implicit. This was a question if we should remove the Group > > establishment transaction or not. I think that there has been no > > consensus during the meeting to change anyhting in the semantics. The > > decissions have been moved to the list. > > > > > > > > > > - Wildcarding needs list discussion > > > > > > OK. > > > > > > > > > > - Return Values: Should full 5-tuple be included in response so > > > that FW/NAT function is transparent to the agent? > > > > > > - Should PER be split into two requests? > > > > > > - Message Queuing. Transactions need to be atomic and operate on > > > first come first served basis. > > > > > > > > May be it is better to write this a question, since there was no > > consensus on this. > > > > > > > > > > - Capabilities exchange: is list in spec complete? > > > > > > - Encryption Method - It was pointed out that the encryption method and > > > keying needs to be decoupled. Issue needs list discussion. > > > > > > It was reported that the NSIS WG had discussed using CASP and TIST to talk > > > to FW/NATs. > > > > > > > > > > > _______________________________________________ > > 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 Wed Nov 27 12:42:32 2002 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 MAA21214 for ; Wed, 27 Nov 2002 12:42:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARHioC12376 for midcom-archive@odin.ietf.org; Wed, 27 Nov 2002 12:44:50 -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 gARHfLv12114; Wed, 27 Nov 2002 12:41: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 gARHeSv12066 for ; Wed, 27 Nov 2002 12:40:28 -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 MAA20942 for ; Wed, 27 Nov 2002 12:37:39 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gARHe4Y48449; Wed, 27 Nov 2002 18:40:04 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 003397A04C; Wed, 27 Nov 2002 18:38:24 +0100 (CET) Message-ID: <3DE50313.5040702@ccrle.nec.de> Date: Wed, 27 Nov 2002 18:38:27 +0100 From: Martin Stiemerling Organization: NEC -- Network Labs Europe 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: Juergen Quittek Cc: midcom@ietf.org, Melinda Shore Subject: Re: [midcom] IETF 55 minutes References: <200211251516.AAY08340@mira-sjc5-4.cisco.com> <3DE3553A.7020804@ccrle.nec.de> <20021127144638.BA1D17B6AF@imap.heidelberg.ccrle.nec.de> 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 Juergen Quittek wrote: > > Martin, maybe we look to similar :-) In Yokohama I made some comments and > the minutes stated "Martin said ...". Now you made a presentation and > the minutes draft says "Juergen presented" ... maybe it's just a > compensation ;-) OK, now it is compensated! ;-) > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Nov 27 16:30:53 2002 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 QAA28340 for ; Wed, 27 Nov 2002 16:30:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARLXCs26029 for midcom-archive@odin.ietf.org; Wed, 27 Nov 2002 16:33: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 gARLWdv25944; Wed, 27 Nov 2002 16:32: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 gARLVDv25912 for ; Wed, 27 Nov 2002 16:31:13 -0500 Received: from smtp014.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28296 for ; Wed, 27 Nov 2002 16:28:23 -0500 (EST) Received: from 207-172-130-132.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com (HELO jpmetower) (jmoisand@207.172.130.132 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 27 Nov 2002 21:31:07 -0000 Message-ID: <002201c2965c$49c685e0$8482accf@cable.rcn.com> From: "Jerome Moisand" To: References: <200211271556.ABA24357@mira-sjc5-c.cisco.com> Subject: Re: [midcom] Midcom proposal: please read Date: Wed, 27 Nov 2002 16:31:02 -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 Yes, I don't disagree with you, Melinda. My sentence was to be read in a context where I was expressing the opinion that the so-called "wide" implementation of SNMP (more precisely SNMPv3 for provisioning) didn't appear as such "intangible", far from it. Was another "intangible" identified and agreed upon? Jerome ----- Original Message ----- From: "Melinda Shore" To: "Jerome Moisand" Cc: Sent: Wednesday, November 27, 2002 10:56 AM Subject: Re: [midcom] Midcom proposal: please read > > I just wanted to express the opinion that we shouldn't shortcut the > > decision-making process. > > To the contrary - the scores among the various protocols as > presented in the evaluation document are very close, and if > there are intangibles that were not possible to quantify > that allow us to short-cut a protracted and likely > unproductive discussion, by all means we should do so. > Obviously if there is non-trivial dissent we won't forge on > ahead with SNMPv3 without more fully considering the other > candidates. We aren't there yet. > > Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Nov 27 16:42:28 2002 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 QAA28890 for ; Wed, 27 Nov 2002 16:42:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARLilT27225 for midcom-archive@odin.ietf.org; Wed, 27 Nov 2002 16:44: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 gARLh6v27152; Wed, 27 Nov 2002 16:43: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 gARLgsv27126 for ; Wed, 27 Nov 2002 16:42:54 -0500 Received: from smtp016.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28828 for ; Wed, 27 Nov 2002 16:40:04 -0500 (EST) Received: from 207-172-130-132.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com (HELO jpmetower) (jmoisand@207.172.130.132 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 27 Nov 2002 21:42:48 -0000 Message-ID: <003901c2965d$eb622d40$8482accf@cable.rcn.com> From: "Jerome Moisand" To: "Melinda Shore" Cc: References: <200211271551.ABA24192@mira-sjc5-c.cisco.com> Subject: Re: [midcom] clarification requested on middlebox concept Date: Wed, 27 Nov 2002 16:42:42 -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 Melinda, thanks for answering. See a few comments below. Still, I'm still struggling a bit with what exactly is meant by middlebox (in its largest meaning), so what's the answer to my initial question? => "I would like to understand if I properly understood the 'middlebox' concept and if a service/subscriber-oriented edge router qualifies." > > In any case, it seems to me that we should keep in mind a bigger picture > > where such 'midcom' transaction (say triggered by a SIP proxy of some > > sort, or a Video app server, etc) would not only act in the NAT/FW side > > of things, but also on the QoS side of things. > > QoS is specifically out of scope. Well, for sure, QoS settings can be achieved by existing mechanisms (e.g. SNMPv3 and Diffserv MIB, or COPS/COPS-PR and Diffserv PIB), but still, my point is that in the context of a NAT/FW middlebox with QoS capabilities (e.g. service-oriented edge router), one would want to perform a single transaction taking care of all settings (NAT-oriented, FW-oriented, QoS-oriented) for a given multimedia session. So the solution for NAT/FW settings needs to be consistent with the solution for QoS settings. This being said, this observation may not help a lot, since SNMPv3, COPS and Diameter are all capable of provisioning QoS-related parameters. Although I would argue that SNMPv3 transaction properties are pretty weak, notably when performing a combination of operations. Ok, SNMP fans, shoot now! ;-) > > Sure, in such a larger picture, some may argue that the RSVP scheme from > > a CPE device is the way to go. > > The NSIS working group is discussing an RSVP-like protocol > that will be used for QoS signaling and also middlebox > communication. Hmmm, I didn't know that. Interesting. Here is a good point for COPS, then. Because if the policy decision is outsourced (QoS, NAT, FW, whatever), then in an RSVP-like model, the middlebox will have to request a policy decision to an external policy server (a policy "pull"). Where in a model where the decision comes from an application server (e.g. SIP proxy) triggering a policy server, then this is a "policy push". Personally, I believe both models (pull and push) are valid. Only COPS can accomodate both. Probably not a point strong enough for a decision, but still a good point. Ok, enough for today. Happy Thanksgiving, all. Cheers, Jerome _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Nov 28 04:42:18 2002 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 EAA23972 for ; Thu, 28 Nov 2002 04:42:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAS9ihD09019 for midcom-archive@odin.ietf.org; Thu, 28 Nov 2002 04:44:43 -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 gAS9fDv08929; Thu, 28 Nov 2002 04:41: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 gAS9esv08909 for ; Thu, 28 Nov 2002 04:40:54 -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 EAA23922 for ; Thu, 28 Nov 2002 04:37:58 -0500 (EST) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAS9egY69840; Thu, 28 Nov 2002 10:40:42 +0100 (CET) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from ccrle.nec.de (martin.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E43F3AE9A; Thu, 28 Nov 2002 10:39:00 +0100 (CET) Message-ID: <3DE5E43B.6090001@ccrle.nec.de> Date: Thu, 28 Nov 2002 10:39:07 +0100 From: Martin Stiemerling Organization: NEC -- Network Labs Europe 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: Jerome Moisand Cc: midcom@ietf.org Subject: Re: [midcom] clarification requested on middlebox concept References: <200211271551.ABA24192@mira-sjc5-c.cisco.com> <003901c2965d$eb622d40$8482accf@cable.rcn.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 Hi Jerome, just a quick shot (inline): Jerome Moisand wrote: [...] >> >>The NSIS working group is discussing an RSVP-like protocol >>that will be used for QoS signaling and also middlebox >>communication. > > > Hmmm, I didn't know that. Interesting. Here is a good point for COPS, then. You should first read the framework and requirements for Midcom in advance, since the COPS protocol and Midcom have (cite the meeting minutes from 54th IETF in Yokohoma) "a glaring mismatch" in their framework. > > Because if the policy decision is outsourced (QoS, NAT, FW, whatever), then > in an RSVP-like model, the middlebox will have to request a policy decision > to an external policy server (a policy "pull"). Where in a model where the > decision comes from an application server (e.g. SIP proxy) triggering a > policy server, then this is a "policy push". Personally, I believe both > models (pull and push) are valid. Only COPS can accomodate both. > > Probably not a point strong enough for a decision, but still a good point. > > Ok, enough for today. Happy Thanksgiving, all. > > Cheers, > Jerome > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Nov 29 12:17:16 2002 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 MAA03557 for ; Fri, 29 Nov 2002 12:17:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gATHJYd10989 for midcom-archive@odin.ietf.org; Fri, 29 Nov 2002 12:19: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 gATHFhv10898; Fri, 29 Nov 2002 12:15: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 gATHExv10833 for ; Fri, 29 Nov 2002 12:14:59 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03457 for ; Fri, 29 Nov 2002 12:12:09 -0500 (EST) Received: from cisco.com (sjc-vpn1-387.cisco.com [10.21.97.131]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with SMTP id gATHEb0J009359; Fri, 29 Nov 2002 09:14:37 -0800 (PST) Received: by cisco.com (sSMTP sendmail emulation); Fri, 29 Nov 2002 12:14:52 -0500 Date: Fri, 29 Nov 2002 12:14:52 -0500 From: Scott W Brim To: Jerome Moisand Cc: Melinda Shore , midcom@ietf.org Subject: Re: [midcom] clarification requested on middlebox concept Message-ID: <20021129171452.GB2052@SBRIM-W2K1> Mail-Followup-To: Scott W Brim , Jerome Moisand , Melinda Shore , midcom@ietf.org References: <200211271551.ABA24192@mira-sjc5-c.cisco.com> <003901c2965d$eb622d40$8482accf@cable.rcn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003901c2965d$eb622d40$8482accf@cable.rcn.com> User-Agent: Mutt/1.4i Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Wed, Nov 27, 2002 04:42:42PM -0500, Jerome Moisand allegedly wrote: > Melinda, > > thanks for answering. See a few comments below. > > Still, I'm still struggling a bit with what exactly is meant by middlebox > (in its largest meaning), so what's the answer to my initial question? > => "I would like to understand if I properly understood the 'middlebox' > concept and if a service/subscriber-oriented edge router qualifies." In the general sense of the term, yes, I believe so. In RFC 3234 we punted and just said "any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host". That sort of begs the question of what's "normal". IMHO an intermediary which is explicitly interacted with at a layer above TCP/UDP is not a middlebox, since the IP-layer e2e interaction is between the end system and the intermediary -- there is nothing exotic going on. Intermediaries which alter packets, or spoof or constrain TCP acks, can be considered as middleboxes (imho). Intermediaries which mess with the diffserv field are not, since that is the intermediaries' responsibility. Tunnel endpoints are not exactly middleboxes, in that they act a lot like ordinary interfaces, but they allow packets to disappear and reappear in an area which might have completely different context, e.g. address scope rules. RFC 3234 is an unfinished bit of work. ..Scott _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Nov 29 17:15:55 2002 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 RAA09503 for ; Fri, 29 Nov 2002 17:15:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gATMIGu23539 for midcom-archive@odin.ietf.org; Fri, 29 Nov 2002 17:18:16 -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 gATMHbv23527; Fri, 29 Nov 2002 17:17:37 -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 gATMGcv23504 for ; Fri, 29 Nov 2002 17:16:38 -0500 Received: from smtp017.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09485 for ; Fri, 29 Nov 2002 17:13:46 -0500 (EST) Received: from 207-172-130-132.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com (HELO jpmetower) (jmoisand@207.172.130.132 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 29 Nov 2002 22:16:31 -0000 Message-ID: <003501c297f4$f62799c0$8482accf@cable.rcn.com> From: "Jerome Moisand" To: References: <200211271551.ABA24192@mira-sjc5-c.cisco.com> <003901c2965d$eb622d40$8482accf@cable.rcn.com> <20021129171452.GB2052@SBRIM-W2K1> Date: Fri, 29 Nov 2002 17:16:25 -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.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [midcom] framework models, related architectures and protocol controversy 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 Scott (Brim), thanks for the clarification. This really helped crystallize my thoughts. So ready for a long windy e-mail? ;-) Describing a middlebox as you did, an edge router which enforces subscriber-specific and service-specific processing (filtering, QoS, policy routing, metering/accounting, etc) on a given data flow (e.g. multimedia or else) can be viewed as a middlebox, and this was definitely my gut feeling. Consequently, I believe it is a useful exercize to make parallels between the midcom (voluntarily focused) problem space, and QoS enforcement problem space. And also to wonder how to deal with network elements which happen to be capable to performing several types of functions (e.g. QoS, Filtering, NAT, FW, etc). My first thought when first looking at the midcom charter (and -voluntarily- before reading the proposed architecture/requirements) was to say: ok, this is nothing but a couple of additional policy rules, more geared at filtering packets & translating IP addresses than the usual QoS stuff. So it looks like a natural extension of the QoS/Diffserv policy-based and very stateful approach described in the "rap" policy framework, and addressed by two different types of model: 1. a "pull" model (e.g. coupling RSVP and COPS) driven by inband signaling 2. a "push" model (e.g. COPS-PR) driven by an application decision. So my first conclusion was "let's just define the appropriate COPS PIB and we're done". Now, when I read the midcom framework/requirements and, afterwards, when trying to understand the controversy about COPS directionality, it became apparent that the issues are linked to the emergence of a third model, allowing multiple instances of stateless proxies to push policy rules to the network element (e.g. router/nat/fw). Well, yes, such model was never envisioned by the COPS designers. Admittedly, it looks a bit strange to perform session management (which is a very stateful activity) using stateless proxies, but the SIP designers clearly demonstrated the value of such architecture (note that, wisely, they didn't exclude a stateful approach either). So it seems to me that we have at least three equally valuable architectures when outsourcing decisions: * decisions triggerred by an inband protocol (ala RSVP/NSIS) => here I believe only COPS addresses this scheme in a satisfying manner * decisions triggerred by an application, which communicates with a stateful policy server => COPS-PR works well, but many people think that SNMPv3 (or even the dreaded CLI) would do the job. * decisions triggerred by an application which can be stateless (ala SIP proxy) => COPS doesn't work well here (at least as currently defined), and I can see the point of using SNMPv3 (or even the dreaded... ok, forget it ;-). Frankly, what disturbs me a lot about the existing midcom framework & requirements is that it is clearly stirred at a given model (the 3rd one), to the exclusion of other models. And I don't believe this is right. I can see scenarios where either one of these models is significantly better than the others. And I believe this is the root cause of the ongoing protocol controversy. Ok, maybe I'm just being a pain, but this brings me to a key question: given this reasoning, given the NSIS "extended charter" factor, shouldn't the 'midcom' framework be extended to accomodate several models/architecture? And isn't that the way to exit the current deadlock where the group appears to be stuck in? Cheers, Jerome PS. Apologies to Diameter fans, I excluded it from my reasoning for simplicity sake, and also... well, because philosophically I have a bit of a hard time to envision a AAA protocol for such 'midcom' application. But no doubt some of you would clearly disagree. Anyway, my main point is not about protocols, but more about framework models & related architectures. ----- Original Message ----- From: "Scott W Brim" To: "Jerome Moisand" Cc: "Melinda Shore" ; Sent: Friday, November 29, 2002 12:14 PM Subject: Re: [midcom] clarification requested on middlebox concept > On Wed, Nov 27, 2002 04:42:42PM -0500, Jerome Moisand allegedly wrote: > > Melinda, > > > > thanks for answering. See a few comments below. > > > > Still, I'm still struggling a bit with what exactly is meant by middlebox > > (in its largest meaning), so what's the answer to my initial question? > > => "I would like to understand if I properly understood the 'middlebox' > > concept and if a service/subscriber-oriented edge router qualifies." > > In the general sense of the term, yes, I believe so. In RFC 3234 we > punted and just said "any intermediary box performing functions apart > from normal, standard functions of an IP router on the data path between > a source host and destination host". That sort of begs the question of > what's "normal". IMHO an intermediary which is explicitly interacted > with at a layer above TCP/UDP is not a middlebox, since the IP-layer e2e > interaction is between the end system and the intermediary -- there is > nothing exotic going on. > > Intermediaries which alter packets, or spoof or constrain TCP acks, can > be considered as middleboxes (imho). Intermediaries which mess with the > diffserv field are not, since that is the intermediaries' > responsibility. Tunnel endpoints are not exactly middleboxes, in that > they act a lot like ordinary interfaces, but they allow packets to > disappear and reappear in an area which might have completely different > context, e.g. address scope rules. RFC 3234 is an unfinished bit of > work. > > ..Scott _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Nov 29 17:45:15 2002 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 RAA10039 for ; Fri, 29 Nov 2002 17:45:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gATMlan24713 for midcom-archive@odin.ietf.org; Fri, 29 Nov 2002 17:47: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 gATMi5v24661; Fri, 29 Nov 2002 17:44: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 gATMhZv24627 for ; Fri, 29 Nov 2002 17:43:35 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09994 for ; Fri, 29 Nov 2002 17:40:42 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gATMhO0R010500; Fri, 29 Nov 2002 14:43:25 -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 ABA90670; Fri, 29 Nov 2002 14:43:26 -0800 (PST) Message-Id: <200211292243.ABA90670@mira-sjc5-c.cisco.com> To: "Jerome Moisand" cc: midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] framework models, related architectures and protocol controversy In-Reply-To: Message from "Jerome Moisand" of "Fri, 29 Nov 2002 17:16:25 EST." <003501c297f4$f62799c0$8482accf@cable.rcn.com> Date: Fri, 29 Nov 2002 17:43:25 -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: , One of the unfortunate things that's happened in the IETF over the past years is the drift away from architectural frameworks that are idiomatic to IP - i.e. they interwork with IP, particularly routing and topology, really, really poorly. I personally think that midcom is one of these, but even if we were to go to end-to-end, on-path signaling there's a need to have application endpoints (or proxies, another can of worms) communicate directly with various sorts of individual middleboxes which may not be on a data path (or cannot be "known" to be on one). The notion of having devices in the network make determinations and push those out to the endpoints has the smell of Bell about it. It's typically not something that will work well in IP networks, where making network elements visible to application endpoints can create a host of problems, ranging from lack of robustness to inter-layer duplication of function to inability to scale with the number of endpoints. By the way, I don't think there is an "ongoing protocol controversy." There's been very little discussion at all. If there's lack of progress it's because of lack of input, not because participants in the working group are at loggerheads. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom