From mailnull@www1.ietf.org Fri Nov 1 09:02:00 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 JAA07490 for ; Fri, 1 Nov 2002 09:01:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1E3v427277 for nsis-archive@odin.ietf.org; Fri, 1 Nov 2002 09:03: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 gA1E3tv27215; Fri, 1 Nov 2002 09:03:55 -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 gA1Djgv24708 for ; Fri, 1 Nov 2002 08:45:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06410; Fri, 1 Nov 2002 08:43:14 -0500 (EST) Message-Id: <200211011343.IAA06410@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 01 Nov 2002 08:43:14 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling 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 Next Steps in Signaling Working Group of the IETF. Title : Analysis of Existing Quality of Service Signaling Protocols Author(s) : J. Manner, X. Fu Filename : draft-ietf-nsis-signalling-analysis-00.txt Pages : 22 Date : 2002-10-31 This document presents a review of existing protocols for signalling the Quality of Service requirements of flows to nodes in an IP network. Protocols are reviewed independently and not compared against the NSIS requirements document nor to RSVP itself. The purpose is to learn from existing work and to avoid common misconceptions about the protocols. A further goal is to avoid to redesign ideas already implemented in another protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-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-nsis-signalling-analysis-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-nsis-signalling-analysis-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-31150436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-signalling-analysis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-signalling-analysis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-31150436.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 1 09:02: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 JAA07503 for ; Fri, 1 Nov 2002 09:02:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1E3xw27366 for nsis-archive@odin.ietf.org; Fri, 1 Nov 2002 09:03: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 gA1E3vv27272; Fri, 1 Nov 2002 09:03: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 gA1Djkv24726 for ; Fri, 1 Nov 2002 08:45:46 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06427; Fri, 1 Nov 2002 08:43:19 -0500 (EST) Message-Id: <200211011343.IAA06427@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 01 Nov 2002 08:43:18 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-threats-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling 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 Next Steps in Signaling Working Group of the IETF. Title : NSIS Threats Author(s) : H. Tschofenig Filename : draft-ietf-nsis-threats-00.txt Pages : 15 Date : 2002-10-31 This threats document provides a starting point to security discussions at the NSIS working group. It therefore tries to help the NSIS interested reader to understand various security considerations in the NSIS Requirements, Framework and Protocol proposals. This document does not describe vulnerabilities of specific NSIS related protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-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-nsis-threats-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-nsis-threats-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-31150448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-threats-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-threats-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-31150448.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 1 09:02: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 JAA07516 for ; Fri, 1 Nov 2002 09:02:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1E40H27433 for nsis-archive@odin.ietf.org; Fri, 1 Nov 2002 09:04: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 gA1E3wv27320; Fri, 1 Nov 2002 09:03: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 gA1Djpv24731 for ; Fri, 1 Nov 2002 08:45:51 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06443; Fri, 1 Nov 2002 08:43:23 -0500 (EST) Message-Id: <200211011343.IAA06443@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 01 Nov 2002 08:43:23 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-rsvp-sec-properties-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling 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 Next Steps in Signaling Working Group of the IETF. Title : RSVP Security Properties Author(s) : H. Tschofenig Filename : draft-ietf-nsis-rsvp-sec-properties-00.txt Pages : 37 Date : 2002-10-31 As the work of the NSIS working group has begun there are also concerns about security and its implication for the design of a signaling protocol. In order to understand the security properties and available options of RSVP a number of documents have to be read. This document tries to summarize the security properties of RSVP and to view them from a different point of view. This work in NSIS is part of the overall process of analyzing other protocols and to learn from their design considerations. This document should also provide a starting point for security discussions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-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-nsis-rsvp-sec-properties-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-nsis-rsvp-sec-properties-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-31150458.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-rsvp-sec-properties-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-rsvp-sec-properties-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-31150458.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 1 11:09: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 LAA19410 for ; Fri, 1 Nov 2002 11:09:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1GBLT11739 for nsis-archive@odin.ietf.org; Fri, 1 Nov 2002 11:11:21 -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 gA1GBHv11723; Fri, 1 Nov 2002 11:11: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 gA1GANv11653 for ; Fri, 1 Nov 2002 11:10:23 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19348 for ; Fri, 1 Nov 2002 11:07:55 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA1GAJQ1016073; Fri, 1 Nov 2002 17:10:19 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WB6ZA0RX; Fri, 1 Nov 2002 17:10:19 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Nov 2002 17:10:58 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE171@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 77ad1bda ca231590 1a36a88e 00000138 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" Cc: "'nsis@ietf.org'" Date: Fri, 1 Nov 2002 17:10:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] two updates and request for timeslots Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi John Please note that we have updated two drafts: "A Proposal for RSVPv2": draft-westberg-proposal-for-rsvpv2-01.txt and "Analysis of Existing QoS Solutions": draft-demeer-nsis-analysis-03.txt We would like to present the issues related to these two drafts during the NSIS WG meeting in Atlanta! We would like to have two time slots! Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 1 13:12: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 NAA26805 for ; Fri, 1 Nov 2002 13:12:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1IEBF23636 for nsis-archive@odin.ietf.org; Fri, 1 Nov 2002 13:14: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 gA1IE9v23611; Fri, 1 Nov 2002 13:14: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 gA1ID2v22513 for ; Fri, 1 Nov 2002 13:13:02 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26670 for ; Fri, 1 Nov 2002 13:10:32 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA1ICva28943; Fri, 1 Nov 2002 10:12:57 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id SAA03101; Fri, 1 Nov 2002 18:12:56 GMT Date: Fri, 1 Nov 2002 18:12:56 GMT Message-Id: <200211011812.SAA03101@gra.isi.edu> To: nsis@ietf.org Cc: braden@ISI.EDU X-Sun-Charset: US-ASCII Subject: [NSIS] Neighbors vs. peers Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , The charm of the English language, I have been told, is that it has a very rich vocabulary (stolen ... err, adapted, from many other languages!) with many subtle shades of meaning. I am reminded of this by the discussion of neighbors vs. peers. Neighbor is a topological relationship, while peer is a power relationship. More concretely, nodes may be neighbors, while protocol processing entities may be peers. We sometimes fuzz the distinction between nodes and programs running in those nodes, but the distinction is nevertheless real. Thus, the revised version of my 2-level signaling document contains the following sentence ["Johnny, use these two words in a sentence!"]: Under the two-level architecture, corresponding [Upper Level Signaling Protoco]] modules in neighbor nodes are peers that communicate using the CSTP level. What we discover directly is neighbors, as a topological fact. This indirectly discovers peers, of course, but why be indirect when you can be direct? Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 1 14:25: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 OAA00137 for ; Fri, 1 Nov 2002 14:25:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1JRIv30425 for nsis-archive@odin.ietf.org; Fri, 1 Nov 2002 14:27: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 gA1JRFv30417; Fri, 1 Nov 2002 14:27: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 gA1JQuv30382 for ; Fri, 1 Nov 2002 14:26:56 -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 OAA00123 for ; Fri, 1 Nov 2002 14:24:25 -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 gA1JQpY46209 for ; Fri, 1 Nov 2002 20:26:51 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A27EF7040A for ; Fri, 1 Nov 2002 20:26:31 +0100 (CET) Date: Fri, 01 Nov 2002 20:26:33 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: nsis@ietf.org Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-threats-00.txt Message-ID: <7244406.1036182393@[192.168.102.207]> In-Reply-To: <200211011343.IAA06427@ietf.org> References: <200211011343.IAA06427@ietf.org> X-Mailer: Mulberry/2.2.0 (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: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit IMHO it should be titled "Signaling Security Threats" or "Security Threats in Signaling" Marcus --On Freitag, 1. November 2002 08:43 -0500 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Next Steps in Signaling > Working Group of the IETF. > > Title : NSIS Threats > Author(s) : H. Tschofenig > Filename : draft-ietf-nsis-threats-00.txt > Pages : 15 > Date : 2002-10-31 > > This threats document provides a starting point to security > discussions at the NSIS working group. It therefore tries to help the > NSIS interested reader to understand various security considerations > in the NSIS Requirements, Framework and Protocol proposals. This > document does not describe vulnerabilities of specific NSIS related > protocols. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-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-nsis-threats-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-nsis-threats-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. -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 1 15:54: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 PAA03938 for ; Fri, 1 Nov 2002 15:54:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1KuGo03318 for nsis-archive@odin.ietf.org; Fri, 1 Nov 2002 15:56: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 gA1KuDv03309; Fri, 1 Nov 2002 15:56: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 gA1KtUv03271 for ; Fri, 1 Nov 2002 15:55: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 PAA03878 for ; Fri, 1 Nov 2002 15:52:59 -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 gA1Kt0Y47612; Fri, 1 Nov 2002 21:55:00 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 1C3233DBA1; Fri, 1 Nov 2002 21:54:41 +0100 (CET) Date: Fri, 01 Nov 2002 21:54:41 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Melinda Shore , nsis@ietf.org Subject: Re: [NSIS] Comments on requirements draft Message-ID: <12534063.1036187681@[192.168.102.207]> In-Reply-To: <200210151727.AAF49587@mira-sjc5-4.cisco.com> References: <200210151727.AAF49587@mira-sjc5-4.cisco.com> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA1KtUv03272 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Melinda, Here my responses to your sugestions. There will be 2 follow-up mails containing (1) draft changes you and others sugested, which I include into the -05 draft. And (2) a list of open issues to be discussed in Atlanta Marcus --On Dienstag, 15. Oktober 2002 13:32 -0400 Melinda Shore wrote: >should be "NSIS Working Group", not "Network Working Group" No, see RFC 2223 >2) this requirement document contains a tremendous amount of >framework material. That material needs to be separated out >and integrated into the framework document. Removed some of that text. >should be "NSIS Working Group", not "Network Working Group" need to check >References need to be split into normative and informative there are no non-normative references >Need to include: > "This memo provides information for the Internet community. This > memo does not specify an Internet standard of any kind. > Distribution of this memo is unlimited." >in "Status of this Memo" section They will finally get this text. So far the document is still a draft and has the draft text in status >Introduction: Change "It does not list any problems of existing >signaling protocols such as RSVP" to something like "We do not >identify problems with existing signaling protocols, such as >RSVP". Better still, delete it. >Change paragraph starting with "QoS is a pretty large field" >to "While we anticipate this protocol will be used for other >applications in addition to QoS signaling, this document >focuses on QoS" or something like that. Deleted [?] > >In terminology: define "Upstream" and "Downstream" > regard this as known. [?] > > >Substance: > >The QoS signaling scenarios belong in the framework >document. Shouldn't there be some scenarios for something >beside QoS, so that we can better generalize the protocol? > >This document should *not* be presenting conceptual models, >just requirements. Conceptual models belong in the >framework. Remove related material, such as introductory >paragraph beginning with "It is clear that the subject of >QoS is uniquely complex" > >Delete first paragraph of terminology section, make sure >that all terms are actually used in the document. >Receiver-initiated signaling protocol and sender-initiated >signaling protocol are not. Get rid of mom-and-apple-pie or >obvious terms, like "QoS Technology." > >"Resource Management Function" definition is far too >abstract. > >Definitions too QoS-y. For example, "Flow" can be defined >in terms of resources requested rather than QoS requested. >"QoS Provisioning" should be "Provisioning," etc. I would >give serious thought to a separate QoS application >requirements document. > >"Trigger" used a lot - I think I probably know what's >intended by it, but I don't know for a fact what it means. >Needs definition. > >Delete section 3, refer to framework > >Delete section 4, refer to framework > >Consistent problem throughout Requirements section: >requirements aren't stated *as* requirements. Application >and transport need to be separated out more cleanly (for >example, 5.3.4 and 5.3.5) > >Use of "may be able to" - what does that mean? Needs to be >more definite. > >5.1.1 Needs to be hardened up lest risks being mom-and-apple- >pie. > I wonder that you think this is apple-pie. I would think the requirement is the most important one for you. >5.1.2 not stated as a requirement. "The NSIS protocol MUST > allow the NI to query for resource availability without > initiating a request." > rephrased >5.1.3 is a weak protocol requirement and is probably > redundant with 5.1.1. It's unclear whether or not > bullet items are requirements > note that the requirements draft does not only cover protocol requirements but also framework requirements. >5.1.4 is related to 5.1.1 and 5.1.3. We should probably try > to distill them down to one or two requirements > They are only 2 with some explanation >5.1.5 is not a protocol requirement > But an architectural. >5.1.7 is related to 5.1.1, 5.1.3, and 5.1.4 See 5.1.4. > Also, not stated as requirement. Sure it is related is in the same section for that reason. reading 5.1.7 I would more go split it up into several requirements > >5.2.1 Not stated as requirement. The first sentence is > closer, I think, to what's intended than the header > (requirement) is. > I don't think the header must be specified as a requirement >5.2.2 Not stated as requirement. Also wrong - this is out > of scope > Here I hesitate to remove it before we hav3 resolved the data-path issue. [...] >5.3.2 Unclear. Possibilities: do you mean that any NSIS > node, whether NI, NF, or NR, should be able to initiate > a teardown, or do you mean that any NSIS node that > releases its resources without a request from the > initiator should send out a teardown, or do you mean > that any NSIS node that releases its resources without a > request from the initiator should send out a notice? > The latter in case of failures. > Don't know what "The goal is to prevent stale state > within the network and adds robustness to the operation > of NSIS. So in other words, an NSIS signaling protocol or > mechanisms MUST provide means for an NSIS entity to > discover and remove local stale state." means. Resource > discovery is covered in 5.1.2, and for a node to > discover its own state is node mechanism and not a > protocol requirement > It meant that there needs to be some house-keeping to prevent stale state. Softe state is one mechanisms how this can be solved. >5.3.4 Some questions: Doesn't the answer depend on the > application (if we're using the two-layer architecture)? > If so, wouldn't the contents of the answer be opaque to > the protocol machinery anyway? > No, the protocol must have means to tell the NSIS initiator what happened to a request. But additional information why the request has failed is pretty service depended (in a two layer architecture) >5.4.1 A bit frameworky. At least make sure this is > consistent with framework > This is a req for the framework not the protocol I assume. >5.4.2 See 5.3.4 and 5.3.5 > as you pointed out before, you would like to remove 5.3.5 and you are happy with this one. But they are different. Put it to the open issue list whether we can remove 5.3.5 >5.4.3 This needs to be rewritten so that it's a protocol > requirement and not a mechanism requirement. Also, it's > a bit application-ish and may depend on the application > I don't agree that this is not a protocol req. But you might be right with the application dependence. -> put it onto the open issues list. >5.4.4. (the word "seamless" makes me queasy) This can be > deleted - it's about NF mechanism > What make you queasy?? >5.5 This section really needs more discussion. Some of it > is either obvious or meaningless, and some of it is > outside the scope of what is even possible. A > requirements document should state requirements in the > form of things like "The NSIS protocol MUST support > aggregation of requests." > I know the problem, but again things cames out of a length agreement process. >5.6 This might be best broken up and redistributed among > other sections > I will do this if I hear other concerns. >5.6.1 I'm not sure what this means - something akin to IPSec > selectors? > NSIS must work in environemnt where you have flow aggregation on the data path. >5.6.2 Can probably be deleted unless a specific protocol > requirement can be identified > Is framework req. and get into a protocol req, but I am not sure done >5.6.4 "The NSIS protocol SHOULD permit signaling both > unidirectional and bidirectional reservation requests." > Delete second paragraph. > No, is needed. Was hard to agree on that one. >5.7.1. "The NSIS protocol MUST support strong authentication > among NSIS nodes. The protocol MUST NOT support the use > of plaintext passwords for authentication or > encryption." Delete the rest. (Note that this is > actually quite difficult to do in practice, particularly > interdomain). > see Hanne's reply >5.7.2 Need to distinguish between application and > transport. Delete frameworky text. > see Hanne's reply >5.7.3 Need to think about protecting individual message > elements as well as entire message > see Hannes' reply >5.7.5 Belongs in framework document > Why? It sounds like an requirement. >5.7.6 Identity of what? Where does this sit in terms of > transport layer/application layer split? Accounting > stuff - application layer > >5.7.7 "The NSIS protocol SHOULD be resilient against > denial-of-service attacks." Currently unclear. Delete > rest of paragraph > >5.7.8 "The NSIS protocol MUST allow encryption of NSIS > messages between NSIS nodes." > >5.7.10 Delete > >5.8.1 Delete the word "efficient" - motherhood/apple pie > Probably for you, but this already went through several iterations to get a compromise >5.9.1 Not a protocol requirement. > We are not talking about protocol requirements only > >5.9.4 Not just the security mechanism, need to identify > considerations for transport and for application. > Also, might want to think about interactions with 5.9.3 Changed >5.9.5 Delete "seamless" Isn't this redundant with 5.8.1? > I think it is not the same, but I rephrased it to try to get the difference. >5.9.6 This is really unclear and should probably be > deleted. There are specific issues with policy-based > routing that need to be addressed in the framework > document and may be reflected back here as specific > protocol requirements - needs more discussion. > >5.10.1 Keep first sentence, delete rest > Sorry, but also this one was a compromisee >5.10.2 Um, how does this work with on-path signaling? Delete > No. -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 1 16:57: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 QAA05872 for ; Fri, 1 Nov 2002 16:57:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1LxFd06863 for nsis-archive@odin.ietf.org; Fri, 1 Nov 2002 16:59:15 -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 gA1LxCv06852; Fri, 1 Nov 2002 16:59: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 gA1Lwfv06827 for ; Fri, 1 Nov 2002 16:58:41 -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 QAA05844 for ; Fri, 1 Nov 2002 16:56:10 -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 gA1LwRot003767; Fri, 1 Nov 2002 13:58:27 -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 AAQ48349; Fri, 1 Nov 2002 13:53:39 -0800 (PST) Message-Id: <200211012153.AAQ48349@mira-sjc5-4.cisco.com> To: brunner@ccrle.nec.de cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Comments on requirements draft In-Reply-To: Message from Marcus Brunner of "Fri, 01 Nov 2002 21:54:41 +0100." <12534063.1036187681@[192.168.102.207]> Date: Fri, 01 Nov 2002 16:58:25 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > there are no non-normative references There will be - the framework document, for example. Even if there aren't, however, the normative references need to be labeled as such. You should probably give draft-rfc-editor-rfc2223bis-03.txt a good read - the IESG and the RFC editors are becoming stricter about formal issues and if the document makes it through WG last call and is sent to the IESG with format problems, John is going to be spanked. > >In terminology: define "Upstream" and "Downstream" > regard this as known. You probably shouldn't. It's not intuitive (I still can't figure out whether a given neighbor lives "up the road" or "down the road") and is considerably less obvious than other terms for which there are definitions in this document, such as "End Host," "Subdomain," and "Path." > >5.1.1 Needs to be hardened up lest risks being mom-and-apple- > >pie. > I wonder that you think this is apple-pie. I would think the requirement is = > > the most important one for you. Not really. When I say "Mom and apple pie" I mean something that's obvious and feels good but isn't particularly meaningful. For example, in this case something like "The information exchanged over the signaling protocol must be in such detail and quantity that it is useful for various technologies" is probably self-evident. There's something that looks more like a requirement in there and it is probably worth restating it so that it's less generic and puts specific requirements on the protocol. > >5.1.3 is a weak protocol requirement and is probably > > redundant with 5.1.1. It's unclear whether or not > > bullet items are requirements > note that the requirements draft does not only cover protocol requirements=20 > but also framework requirements. Okay, but "modular" is one of those words, like "scalability," that isn't very useful without an explanation of specifically what is meant. The examples given don't necessarily have very much to do with modularity. For example "Work over any kind of network" might be an artifact of modularity, but it might be just plain old IP. "Uni- and bi-directional reservations are possible" isn't really an example of modularity. Those themselves aren't descriptions of what is meant by the word "modular." I think I know what you're trying to get at, and maybe you could extract some language from Bob's "Two-Level" draft. > I don't think the header must be specified as a requirement The requirements need to be presented consistently. In the beginning they're stated in the section headers and later they're placed in the body of each section. It's not necessarily that they belong in the header but that they be treated consistently. BTW, my favorite requirements document as far as presentation is the one produced by the sacred working group. > Here I hesitate to remove it before we hav3 resolved the data-path issue. I think this has been pretty much resolved by fiat (the ADs). > It meant that there needs to be some house-keeping to prevent stale state.=20 > Softe state is one mechanisms how this can be solved. It's unclear as stated, I think. If you're saying that a NE must release expired resources that's a node mechanism and is out-of-scope. Are you trying to say this? "When an NSIS Entity detects a failure and releases a reservation, it MUST notify other NSIS Entities along the reservation's path." It's not clear exactly what you're requiring. (BTW, the second paragraph in 5.3.2 suffers from the "MUST be able to" problem) > >5.5 This section really needs more discussion. Some of it > > is either obvious or meaningless, and some of it is > > outside the scope of what is even possible. A > > requirements document should state requirements in the > > form of things like "The NSIS protocol MUST support > > aggregation of requests." > I know the problem, but again things cames out of a length agreement=20 > process. That doesn't make them correct, as you know. Much of this section falls into the "Mom and apple pie" category, since the alternatives to what you're saying could be things like "The NSIS protocol MUST be inefficient" or "The NSIS protocol must consume vast amounts of bandwidth." It's better in these cases to be specific about what the requirements are, like saying that the protocol MUST support aggregation of requests or that the protocol MUST NOT require more than a single end-to-end round trip to install a reservation (unless there are errors). > >5.7.5 Belongs in framework document > Why? It sounds like an requirement. The material beginning with "It is a well-known ... " isn't requirements text and should be moved into the framework document. > >5.8.1 Delete the word "efficient" - motherhood/apple pie > > Probably for you, but this already went through several iterations to get a = > compromise "Efficient" took several iterations and a compromise? > >5.10.1 Keep first sentence, delete rest > Sorry, but also this one was a compromisee Again, I'm not saying to delete the requirement, but to delete the chatty stuff. > >5.10.2 Um, how does this work with on-path signaling? Delete > > > No. I think it needs a lot more discussion. For one thing it may be an implementation/mechanism issue rather than a protocol issue. For another, the text doesn't necessarily match the requirement. I'd put it high on the "needs resolution" list. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 1 17:03: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 RAA06182 for ; Fri, 1 Nov 2002 17:03:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1M57807608 for nsis-archive@odin.ietf.org; Fri, 1 Nov 2002 17:05: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 gA1M55v07593; Fri, 1 Nov 2002 17:05: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 gA1M4Tv07542 for ; Fri, 1 Nov 2002 17:04:29 -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 RAA06149 for ; Fri, 1 Nov 2002 17:01: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 gA1M4LY48440 for ; Fri, 1 Nov 2002 23:04:21 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id F3864719C9 for ; Fri, 1 Nov 2002 23:04:01 +0100 (CET) Date: Fri, 01 Nov 2002 23:04:02 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: nsis@ietf.org Message-ID: <16695967.1036191842@[192.168.102.207]> X-Mailer: Mulberry/2.2.0 (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: [NSIS] updated req draft -05 submitted Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I have submitted the next revision of the reqirements draft. Here is the change log Changes 04 -> 05 1) removed QoS specifics as far as possible, still used as examples at several places. 2) Removed text from Section 1-3. 3) Changes exclusion 11 on "Handoff decision and trigger sources" into: 11. Handoff decision and trigger sources: An NSIS protocol is not used to trigger handoffs in mobile IP, nor is it used to decide whether to handoff or not. As soon as or in some situation even before a handoff happened, an NSIS protocol might be used for signaling for QoS again. The basic underlying assumption is that the route comes first (defining the path) and the signaling comes after it (following the path). This doesn't prevent a signaling application at some node interacting with something that modifies the path, but the requirement is then just for NSIS to live with that possibility. However, NSIS must interwork with several protocols for mobility management. 4) change in section 5 From: "All of them are not strictly defined and should not be regarded as that, but should give a feeling about where in the network we have different requirements concerning signaling." To: "These divisions between network types are not strict and do not appear in all networks, but where they do exist they may influence signaling requirements and will be highlighted as necessary." 5) change req 5.2.3 SHOULD in 2nd paragraph changed to lower-case 6) changed title of 5.3 into "Messaging" 7) req 5.3.3 changed From: SHOULD be able to notify To: SHOULD notify 8) change req 5.3.4 Second MAY is now lowercase 9) req 5.6.3 changed sender -> NSIS Initiator, receiver into NSIS Responder 10) created separate req section with the NF initiation req. Keeps the same text 11) removed last sentence of req 5.7.4 12) changed req 5.9.2 From: "The solution MUST NOT constrain either to IPv4 or IPv6" To: "The NSIS protocol MUST support IPv4 and IPv6." 13) change req 5.9.4 "SHOULD provide hooks for AAA protocols" From: The security mechanism SHOULD be developed with respect to be able to collect usage records from one or more network elements. To: The NSIS SHOULD be developed with respect to be able to collect usage records from one or more network elements. 14) remove text from req 5.9.5 New it says: "An NSIS protocol SHOULD interwork with seamless handoff protocols such as context transfer and candidate access router (CAR) discovery." 15) Change requirement 5.10.3 From: "NSIS peers SHOULD be able to detect the malfunctioning peer. It may notify the NSIS Initiator or another NSIS entity involved in the signaling process. The NSIS peer may handle the problem itself e.g. switching to a backup NSIS entity. In the latter case note that synchronization of state between the primary and the backup entity is needed." To: "NSIS peers SHOULD be able to detect the malfunctioning peer. It SHOULD notify the NSIS Initiator or another NSIS entity involved in the signaling process. The NSIS peer may handle the problem itself e.g. switching to a backup NSIS entity. " 16) Section 6: changed "threads" should be "threats" -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 1 17:31: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 RAA06974 for ; Fri, 1 Nov 2002 17:31:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1MXIP09276 for nsis-archive@odin.ietf.org; Fri, 1 Nov 2002 17:33: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 gA1MXCv09267; Fri, 1 Nov 2002 17:33: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 gA1MWWv09226 for ; Fri, 1 Nov 2002 17:32:32 -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 RAA06942 for ; Fri, 1 Nov 2002 17:30:00 -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 gA1MWPY48743 for ; Fri, 1 Nov 2002 23:32:25 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id BF7E4719C9 for ; Fri, 1 Nov 2002 23:32:05 +0100 (CET) Date: Fri, 01 Nov 2002 23:32:06 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: nsis@ietf.org Message-ID: <18379708.1036193526@[192.168.102.207]> X-Mailer: Mulberry/2.2.0 (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: [NSIS] Req-Draft: Open Issue 1: Local Information Exchange Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Req-Draft: Open Issue 1: Local Information Exchange ------------------------------------------ We have 2 requirements 5.3.5 and 5.4.2 about this. What is required a) add domain local information to NSIS protocol messages and/or b) allow to use NSIS messges for domain internal communication, e.g., coordination between several NSIS forwarders -05 text of the two reqs 5.3.5 Local information exchange The signaling protocol MUST be able to exchange local information between NSIS Forwarders located within one single administrative domain. Local information might, for example, be IP addresses, severe congestion notification, notification of successful or erroneous processing of signaling messages. In some cases, the NSIS signaling protocol MAY carry identification of the NSIS Forwarders located at the boundaries of a domain. However, the identification of edge should not be visible to the end host (NSIS Initiator) and only applies within one administrative domain. 5.4.2 Possibility to add and remove local domain information It SHOULD be possible for the Resource Management Function to add and remove local scope elements. E.g., at the entrance to a domain domain-specific information is added, which is used in this domain only, and the information is removed again when a signaling message leaves the domain. The motivation is in the economy of re-use the protocol for domain internal signaling of various information pieces. Where additional information is needed within a particular domain, it should be possible to carry this at the same time as the end-to-end information. -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 1 17:32: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 RAA07001 for ; Fri, 1 Nov 2002 17:32:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1MY4l09316 for nsis-archive@odin.ietf.org; Fri, 1 Nov 2002 17:34: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 gA1MY2v09309; Fri, 1 Nov 2002 17:34: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 gA1MXjv09291 for ; Fri, 1 Nov 2002 17:33:45 -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 RAA06969 for ; Fri, 1 Nov 2002 17:31:13 -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 gA1MXbY48767 for ; Fri, 1 Nov 2002 23:33:37 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id AC03071991 for ; Fri, 1 Nov 2002 23:33:18 +0100 (CET) Date: Fri, 01 Nov 2002 23:33:19 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: nsis@ietf.org Message-ID: <18452713.1036193599@[192.168.102.207]> X-Mailer: Mulberry/2.2.0 (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: [NSIS] Req-Draft: Open Issue 2: Independence of reservation identifier Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Req-Draft: Open Issue 2: Independence of reservation identifier ---------------------------------------------------- - see thread on NSIS and mobility - is the req needed? - is it needed for a general NSIS base protocol? Or is it application dependent? 5.4.3 Independence of reservation identifier A reservation identifier MUST be independent of the flow identifier (flow end-points). Various scenarios in the mobility area require this independence because flows resulting from handoff might have changed end-points etc. but still have the same service requirement. Also several proxy-based signaling methods profit from such as independence. -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 1 17:33: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 RAA07029 for ; Fri, 1 Nov 2002 17:33:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1MZ5Z09406 for nsis-archive@odin.ietf.org; Fri, 1 Nov 2002 17:35:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1MZ3v09392; Fri, 1 Nov 2002 17:35: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 gA1MYCv09332 for ; Fri, 1 Nov 2002 17:34: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 RAA06994 for ; Fri, 1 Nov 2002 17:31:41 -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 gA1MY5Y48781 for ; Fri, 1 Nov 2002 23:34:05 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6FE0D71991 for ; Fri, 1 Nov 2002 23:33:46 +0100 (CET) Date: Fri, 01 Nov 2002 23:33:47 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: nsis@ietf.org Message-ID: <18480473.1036193627@[192.168.102.207]> X-Mailer: Mulberry/2.2.0 (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: [NSIS] Req-Draft: Open Issue 3: Replay protection Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Req-Draft: Open Issue 3: Replay protection ------------------------------- Is req 5.7.4 a MUST or SHOULD SHOULD because it is too complicated to do 5.7.4 Replay protection To prevent replay of previous signaling messages the signaling protocol MUST provide means to detect old i.e. already transmitted signaling messages. A solution must cover issues of synchronization problems in the case of a restart or a crash of a participating network element. -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 1 17:34: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 RAA07082 for ; Fri, 1 Nov 2002 17:34:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1MaAa09521 for nsis-archive@odin.ietf.org; Fri, 1 Nov 2002 17:36:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1Ma8v09514; Fri, 1 Nov 2002 17:36: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 gA1MZrv09455 for ; Fri, 1 Nov 2002 17:35:53 -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 RAA07051 for ; Fri, 1 Nov 2002 17:33: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 gA1MZkY48816 for ; Fri, 1 Nov 2002 23:35:46 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B7CCA71991 for ; Fri, 1 Nov 2002 23:35:26 +0100 (CET) Date: Fri, 01 Nov 2002 23:35:27 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: nsis@ietf.org Message-ID: <18580787.1036193727@[192.168.102.207]> X-Mailer: Mulberry/2.2.0 (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: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Req-Draft: Open Issue 4: Confidentiality of signaling messages --------------------------------------------------- Proposal to change Req 5.7.8 "The NSIS protocol MUST allow encryption of NSIS messages between NSIS nodes." Currently it says 5.7.8 Confidentiality of signaling messages Based on the signaling information exchanged between nodes participating in the signaling protocol an adversary may learn both the identities and the content of the signaling messages. To prevent this from happening, confidentiality of the signaling message in a hop-by-hop manner MAY be provided. Note that the protection can be provided on a hop-by-hop basis for most message payloads since it is required that entities which actively participating in the signaling protocol must be able to read and eventually modify the content of the signaling messages." -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 1 17:36: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 RAA07140 for ; Fri, 1 Nov 2002 17:36:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA1Mc6710186 for nsis-archive@odin.ietf.org; Fri, 1 Nov 2002 17:38: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 gA1Mc4v10178; Fri, 1 Nov 2002 17:38: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 gA1Mbqv10156 for ; Fri, 1 Nov 2002 17:37: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 RAA07135 for ; Fri, 1 Nov 2002 17:35: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 gA1MbjY48852 for ; Fri, 1 Nov 2002 23:37:45 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 3A1BA71991 for ; Fri, 1 Nov 2002 23:37:26 +0100 (CET) Date: Fri, 01 Nov 2002 23:37:26 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: nsis@ietf.org Message-ID: <18700299.1036193846@[192.168.102.207]> X-Mailer: Mulberry/2.2.0 (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: [NSIS] Req-Draft: Open Issue 5 Req 5.7.10 Hooks ... Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Req-Draft: Open Issue 5 Req 5.7.10 Hooks ... -------------------------------------------- Proposal to remove req 5.7.10 " Hooks with Authentication and Key Agreement protocols" 5.7.10 Hooks with Authentication and Key Agreement protocols This requirement covers two subsequent steps before a signaling protocol is executed and the required hooks. First there is a need to agree on a specific authentication protocol. Later this protocol is executed and provides authentication and establishes the desired security associations. Using these security associations it is then possible to exchange secured signaling messages. The signaling protocol implementation SHOULD provide hooks to interact with protocols that allow the negotiation of authentication and key agreement protocols. Although the negotiation of an authentication and key management protocol within the signaling protocol may be outside the scope it is still required to trigger this exchange in case that no such security association is available. This requirement originates from the fact that more than one key management protocol may be used to provide a security association for the signaling protocol. Hence the communicating entities must be capable to agree on a specific authentication. The selected authentication and key agreement protocol must however be able to create a security association that can be used within the signaling protocol. Key management protocols typically require a larger number of messages to be transmitted to allow a session key and the corresponding security association to be derived. To avoid the complex issue of embedding individual authentication and key agreement protocols into a specific signaling protocol it is required that most of these protocols are executed independently (prior to the signaling protocol) and although the key management protocol may be independent there must be a way for the signaling protocol to access and use available (i.e. already established) security associations to avoid executing a separate key management protocol (or instance of the same protocol) for protocols that closely operate together. If no such security association exists then there SHOULD be means for the signaling protocol to dynamically trigger such a protocol. -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Nov 2 20:41: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 UAA16907 for ; Sat, 2 Nov 2002 20:41:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA31hww02280 for nsis-archive@odin.ietf.org; Sat, 2 Nov 2002 20:43: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 gA31huv02275; Sat, 2 Nov 2002 20:43: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 gA31gUv02251 for ; Sat, 2 Nov 2002 20:42:30 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16839 for ; Sat, 2 Nov 2002 20:39:56 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 3 Nov 2002 01:42:21 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5CED@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Date: Sun, 3 Nov 2002 01:42:20 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] framework update Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , dear all, i've been trying to put together a framework update before the official atlanta deadline. basically, the aim is to clarify terminology issues and eliminate some ambiguities of scope/emphasis that comments on the mailing list have thrown up, and *not* to make any substantive technical changes. with any luck, this should make it easier to progress on the real subjects. i've listed the changes in extremely abbreviated form below (in fact, it's the change log from my working version). if any of these ring alarm bells with people, let me know and i'll try to back them out before the submission. however, i've not seen continuing objections to any of them (except that there will never be enthusiastic agreement on terminology, but that's life...) cheers, robert h. ========================================================================= 1. Editorial fix in 'classifier' definition (section 2). 2. Added definition of 'peer determination' (finding the right peer for a given flow) (section 2). 3. Added definitions for 'sender' and 'receiver' refers to role relative to data packets always (section 2, and minor fixes in sections 3.2.6 and 3.2.7). 4. Updated references. 5. Replaced 'peer session' with 'peer relationship' and 'peer session addressing' with 'peer-peer addressing' (throughout), and attempted redraw of Figure 1 to make it less session-like (corresponding changes in Figure 4, Figure 7, Figure 8, and Figure 9). 6. Added terms for transport and signaling layer protocols (NTLP/NSLP) and explanation in new section 3.1.3. New terms used throughout (significant rewrites to section 4, although this should be at most a change of emphasis rather than technical content). 7. Clarified that section 3.2 is about possible modes of operation (listing alternatives, not all to be supported). 8. Clarified 'local object' definition in 3.2.4. 9. Added working assumption in 3.3.1 that end-to-end routing is done by sequentially determining the right peer in the NTLP, and no-one discovers or uses global topology information for this. 10. Added working assumption in 3.3.3 that NTLP operates only locally. 11. Slightly trimmed 3.3.5 in preparation for turning it into a discussion about NSIS layering boundaries. 12. Clarified in section 4.2 that peer determination doesn't have to be a separate capability, just that it could additionally be done separately. 13. Fixed some flow identification terminology inconsistencies in section 5.3.1. ======================================================================== _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Nov 3 17:12:49 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 RAA15799 for ; Sun, 3 Nov 2002 17:12:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA3MEqk08744 for nsis-archive@odin.ietf.org; Sun, 3 Nov 2002 17:14: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 gA3MEnv08725; Sun, 3 Nov 2002 17:14: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 gA3MA1v08663 for ; Sun, 3 Nov 2002 17:10:01 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15742 for ; Sun, 3 Nov 2002 17:07:27 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA3M9oa17603; Sun, 3 Nov 2002 14:09:50 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id WAA03714; Sun, 3 Nov 2002 22:09:50 GMT Date: Sun, 3 Nov 2002 22:09:50 GMT Message-Id: <200211032209.WAA03714@gra.isi.edu> To: nsis@ietf.org Cc: braden@ISI.EDU, lindell@ISI.EDU, john.loughney@nokia.com, mankin@ISI.EDU X-Sun-Charset: US-ASCII Subject: [NSIS] Updated 2-level document Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Folks, Some time ago John asked me to update my 2-level signaling draft. Unfortunately a succession of urgent tasks kept me from doing it until the very last minute ... today ... but it's now done and submitted. I believe it is more correct and more complete, and I hope it is clearer. In private discussions with some members of the WG, I have found that some important aspects of the previous document were misunderstood; I hope they will now be clearer. It is available online at: http://www.isi.edu/~braden/nsis/draft-braden-2level-signaling-01.txt and also on the RSVP web page www.isi.edu/rsvp/ under publications. And of course it will (eventually) roll out of the IETF repository. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 03:47: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 DAA06566 for ; Mon, 4 Nov 2002 03:47:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA48nbu12132 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 03:49: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 gA48nYv12125; Mon, 4 Nov 2002 03:49: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 gA48mwv12097 for ; Mon, 4 Nov 2002 03:48:58 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06559 for ; Mon, 4 Nov 2002 03:46:19 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA48mJO17815 for ; Mon, 4 Nov 2002 10:48:19 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Nov 2002 10:48:44 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 4 Nov 2002 10:48:44 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 4 Nov 2002 10:48:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-threats-00.txt Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 4 Nov 2002 10:48:43 +0200 Message-ID: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-threats-00.txt Thread-Index: AcKB3LX5KufYckEZRFetFf0dHCPP/ACAjAPQ To: , X-OriginalArrivalTime: 04 Nov 2002 08:48:43.0840 (UTC) FILETIME=[FB179400:01C283DE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA48mwv12098 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Marcus, I think you suggestions are reasonable. John > -----Original Message----- > From: ext Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 01 November, 2002 21:27 > To: nsis@ietf.org > Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-threats-00.txt > > > IMHO it should be titled "Signaling Security Threats" or > "Security Threats in Signaling" > > Marcus > > --On Freitag, 1. November 2002 08:43 -0500 > Internet-Drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Next Steps in > Signaling > > Working Group of the IETF. > > > > Title : NSIS Threats > > Author(s) : H. Tschofenig > > Filename : draft-ietf-nsis-threats-00.txt > > Pages : 15 > > Date : 2002-10-31 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 03:51: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 DAA06758 for ; Mon, 4 Nov 2002 03:51:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA48s7c12270 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 03:54: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 gA48s4v12244; Mon, 4 Nov 2002 03:54: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 gA48rEv12221 for ; Mon, 4 Nov 2002 03:53:14 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06659 for ; Mon, 4 Nov 2002 03:50:35 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA48rTB03610 for ; Mon, 4 Nov 2002 10:53:29 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Nov 2002 10:52:15 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 4 Nov 2002 10:52:15 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 4 Nov 2002 10:52:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] Neighbors vs. peers Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 4 Nov 2002 10:52:14 +0200 Message-ID: Thread-Topic: [NSIS] Neighbors vs. peers Thread-Index: AcKB0o+M9XWFNOYzQEyvRqkXUUm4IgCDMnwg To: , X-OriginalArrivalTime: 04 Nov 2002 08:52:15.0232 (UTC) FILETIME=[79177000:01C283DF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA48rEv12222 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Bob, > Thus, the revised version of my 2-level signaling document > contains the following sentence ["Johnny, use these two words in a > sentence!"]: > > Under the two-level architecture, corresponding [Upper Level > Signaling Protoco]] modules in neighbor nodes are peers > that communicate using the CSTP level. > > What we discover directly is neighbors, as a topological fact. > This indirectly discovers peers, of course, but why be indirect > when you can be direct? This sounds like a reasonable solution for the terminology. If someone has a problem with it, I expect that they have a better suggestion. best regards, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 03:54: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 DAA06908 for ; Mon, 4 Nov 2002 03:54:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA48uE312407 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 03:56: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 gA48uAv12399; Mon, 4 Nov 2002 03:56: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 gA48txv12356 for ; Mon, 4 Nov 2002 03:55:59 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06868 for ; Mon, 4 Nov 2002 03:53:20 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA48uEB06122 for ; Mon, 4 Nov 2002 10:56:14 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Nov 2002 10:55:46 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 4 Nov 2002 10:55:46 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 4 Nov 2002 10:55:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Comments on requirements draft Date: Mon, 4 Nov 2002 10:55:44 +0200 Message-ID: Thread-Topic: [NSIS] Comments on requirements draft Thread-Index: AcKB6SbhETka1ulwQpOqLKtDz941twB9oQwg To: , , X-OriginalArrivalTime: 04 Nov 2002 08:55:46.0030 (UTC) FILETIME=[F6BCA8E0:01C283DF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA48txv12357 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Marcus, > >should be "NSIS Working Group", not "Network Working Group" > > need to check It should be NSIS Working Group. > >References need to be split into normative and informative > > there are no non-normative references The split suggested is: Normative are documents which must be read to understand the document in question; informative (non-normative) are references which provide additional / background info. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 04:00: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 EAA07066 for ; Mon, 4 Nov 2002 04:00:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA492CF12933 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 04:02: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 gA4927v12887; Mon, 4 Nov 2002 04:02: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 gA490lv12540 for ; Mon, 4 Nov 2002 04:00:47 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06999 for ; Mon, 4 Nov 2002 03:58:08 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA4909O27830 for ; Mon, 4 Nov 2002 11:00:09 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Nov 2002 10:59:36 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 4 Nov 2002 10:59:36 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 4 Nov 2002 10:59:36 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 4 Nov 2002 10:59:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message Subject: RE: nsis mobility interactions (was: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 4 Nov 2002 10:59:26 +0200 Message-ID: Thread-Topic: nsis mobility interactions (was: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt) Thread-Index: AcKAvKBuHF/+2KeSQvmVlBH9Q0adeADI2UEw To: Cc: X-OriginalArrivalTime: 04 Nov 2002 08:59:35.0979 (UTC) FILETIME=[7FCC17B0:01C283E0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA490lv12541 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Rüdiger, What I take from Bob's mail is that an NSIS protocol may wish to have a neighbor discovery process, so it knows what are the NSIS hops around it. This could be very useful when nodes fail and things need to be re-routed / re-signaled. This type of thing is not explicitly off-path signaling, so I think it is within scope. This could be considered as part of the building blocks of the protocol. Additionally, what I think of as out of scope is for NSIS endpoints to try to discover different services which a network may provide. Am I addressing your concern? John > -----Original Message----- > From: ext Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 31 October, 2002 10:26 > To: braden@ISI.EDU; brunner@ccrle.nec.de; robert.hancock@roke.co.uk > Cc: nsis@ietf.org > Subject: Re: nsis mobility interactions (was: RE: [NSIS] Some comments > on draft-ietf-nsis-req-04.txt) > > > Hi John, > > I support Bob's suggestion and would like to ask you about your > and the AD's position. > > Regards, Rüdiger > > Bob Braden wrote: > > There is a subtle difference between neighbor discovery and > routing. Discovery allows a node to find all the neighbor > nodes to which signaling messages might be forwarded. > Routing determines which actual next hops are used for > forwarding a particular signaling message. Neighbor > discovery involves only local information,\ while routing > involves global information in general. > > I can imagine that the new QoS signaling protocol [I refuse > to call it "NSIS", because I think that's a dumb name for > a protocol] might want to have a neighbor discovery > mechanism (roughly an "up/down" protocol), but it might > still want to route signaling packets using the same > routing that is used for data packets. Note that if you > use "some different routing mechanism", you almost > certainly have times when data routing differs from > signal routing, which is busted. > > Thanks, > > Bob Braden > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 05:42: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 FAA08577 for ; Mon, 4 Nov 2002 05:42:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4AiNh17965 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 05:44:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4AiLv17957; Mon, 4 Nov 2002 05:44: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 gA4AhQv17915 for ; Mon, 4 Nov 2002 05:43:26 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08539 for ; Mon, 4 Nov 2002 05:40:57 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA4AhPKV014981 for ; Mon, 4 Nov 2002 11:43:25 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WB6ZJ6Q6; Mon, 4 Nov 2002 11:43:25 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Nov 2002 11:43:25 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE172@enleent103.nl.eu.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Georgios Karagiannis (ELN)" To: nsis@ietf.org Date: Mon, 4 Nov 2002 11:43:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] Updated: draft-westberg-proposal-for-rsvpv2-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Please note that the submission of the draft "A Proposal for RSVPv2" , draft-westberg-proposal-for-rsvpv2-01.txt has been announced by the IETF and is located at: http://www.ietf.org/internet-drafts/draft-westberg-proposal-for-rsvpv2-01.txt The main differences between the 00 version and this version are associated to the fact that the two level architecture of internet signaling, introduced in draft-braden-2level-signal-arch-00.txt, is used. If you have any comments please let me know! Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 08:25: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 IAA11931 for ; Mon, 4 Nov 2002 08:25:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4DRI525231 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 08:27: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 gA4DRFv25224; Mon, 4 Nov 2002 08:27: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 gA4DQNv25204 for ; Mon, 4 Nov 2002 08:26:23 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11896 for ; Mon, 4 Nov 2002 08:23:54 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 4 Nov 2002 14:25:44 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Nov 2002 14:25:37 +0100 Message-Id: From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: nsis mobility interactions (was: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt) Date: Mon, 4 Nov 2002 14:25:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA4DQOv25205 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi John, As already mentioned, sounds good to me. What's the AD's view? > John Loughney wrote: > What I take from Bob's mail is that an NSIS protocol may wish > to have a neighbor discovery process, so it knows what are > the NSIS hops around it. This could be very useful when nodes > fail and things need to be re-routed / re-signaled. This > type of thing is not explicitly off-path signaling, so I think > it is within scope. This could be considered as part of the > building blocks of the protocol. > > I support Bob's suggestion and would like to ask you about your > > and the AD's position. > > > > Regards, Rüdiger > > > > Bob Braden wrote: > > > > There is a subtle difference between neighbor discovery and > > routing. Discovery allows a node to find all the neighbor > > nodes to which signaling messages might be forwarded. > > Routing determines which actual next hops are used for > > forwarding a particular signaling message. Neighbor > > discovery involves only local information,\ while routing > > involves global information in general. > > > > I can imagine that the new QoS signaling protocol [I refuse > > to call it "NSIS", because I think that's a dumb name for > > a protocol] might want to have a neighbor discovery > > mechanism (roughly an "up/down" protocol), but it might > > still want to route signaling packets using the same > > routing that is used for data packets. Note that if you > > use "some different routing mechanism", you almost > > certainly have times when data routing differs from > > signal routing, which is busted. > > > > Thanks, > > > > Bob Braden > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 09:27: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 JAA14233 for ; Mon, 4 Nov 2002 09:27:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4ETHt28320 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 09:29: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 gA4ETEv28313; Mon, 4 Nov 2002 09:29: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 gA4ES8v28289 for ; Mon, 4 Nov 2002 09:28:08 -0500 Received: from iramx1.ira.uni-karlsruhe.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14185 for ; Mon, 4 Nov 2002 09:25:39 -0500 (EST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx1.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 188iCy-0004a3-00 for ; Mon, 04 Nov 2002 15:28:04 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=tpce10.ipv6.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 188iCz-0006hc-00 for ; Mon, 04 Nov 2002 15:28:05 +0100 Received: from tpce10.ipv6.tm.uka.de (localhost [127.0.0.1]) by tpce10.ipv6.tm.uka.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id gA4ERZe18651 for ; Mon, 4 Nov 2002 15:27:35 +0100 Message-Id: <200211041427.gA4ERZe18651@tpce10.ipv6.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: nsis@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Nov 2002 15:27:35 +0100 From: Roland Bless Subject: [NSIS] Updated: draft-schelen-nsis-opopsig-01 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi, a new version of the draft-schelen-nsis-opopsig was just submitted by Olov to the I-D repository. The draft has undergone major revisions (it is hopefully less solution-oriented) and was adapted to the new terms path-coupled/path-decoupled. Until it is published by the Internet-Drafts editor you can get it from: http://www.operax.com/drafts/draft-schelen-nsis-opopsig-01.txt or http://www.tm.uka.de/doc/2002/draft-schelen-nsis-opopsig-01.txt Title: "Path-coupled and Path-decoupled Signaling for NSIS" Abstract: The NSIS Work group will develop the requirements, architecture and protocols for the next IETF steps on signaling. Two approaches for a signaling model have been discussed: path-coupled and path-decoupled (previously denoted as on-path and off-path). This draft provides a conceptual comparison between path-coupled and path-decoupled signaling together with reasons for why an NSIS protocol should be designed to support both cases. The collection of data objects to be carried by the protocol should basically be the same in both cases and will evolve over time as new usages for NSIS protocol are identified. The differences between the two flavors of this NSIS protocol are then explained. -- Roland Bless -- e-Mail: bless@tm.uka.de WWW: http://www.tm.uka.de/~bless Institute of Telematics, University of Karlsruhe, Germany _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 09:41: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 JAA14614 for ; Mon, 4 Nov 2002 09:41:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4Eh6529435 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 09:43: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 gA4Eh4v29428; Mon, 4 Nov 2002 09:43: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 gA4Egmv29397 for ; Mon, 4 Nov 2002 09:42:48 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14601 for ; Mon, 4 Nov 2002 09:40:18 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Nov 2002 14:42:44 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA68F@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Date: Mon, 4 Nov 2002 14:42:42 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] Updated framework draft-ietf-nsis-fw-01 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi all, as foreshadowed yesterday, we've updated the framework document. The changes are either clarifications (we think) or part of the sloooow convergence towards a universally agreed terminology. while we wait for it to work through the i-d queue, you can find a copy at: http://www.epic.roke.co.uk/epic/draft-ietf-nsis-fw-01.txt still plenty of open issues to get your teeth into! cheers, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 10:14: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 KAA17297 for ; Mon, 4 Nov 2002 10:14:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4FG9q31807 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 10:16:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4FG7v31800; Mon, 4 Nov 2002 10:16: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 gA4FEbv31665 for ; Mon, 4 Nov 2002 10:14:37 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17195 for ; Mon, 4 Nov 2002 10:12:07 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gA4F6um10361; Mon, 4 Nov 2002 16:06:56 +0100 To: mshore@cisco.com, robert.hancock@roke.co.uk Cc: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 4 Nov 2002 16:14:19 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/04/2002 16:14:24 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [NSIS] NE functionality Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Melinda, all, This mail is a follow-up to one of the remarks on the framework draft you sent a while ago. I have checked the requirements draft like you suggested. For reference, I included your comment. [ms] 3.3.2 The first sentence is *excellent* - IETF documents need more of this kind of thing. Otherwise section needs to be aligned with requirements document - currently they're somewhat out of alignment The framework draft currently states: More in particular, it is not clear whether: *) an NF can request, modify or release a reservation. If it cannot, it needs to notify the NI in order to perform these functions. *) an NR can modify and release a reservation. Even if the NR can reject or accept the reservation with modification, it might still be required to notify the NI to signal the release or modification. The idea of this section is/was to explore whether all NEs should have equal capabilities or whether there would be operations on reservations that could only be performed by the NI and/or NR. I found three section in the requirements draft that refer to the capabilities of and/or functions performed by the NEs: 5.3.2 Possibility for automatic release of resources after failure: states that an NF needs to be able to release reservations in case of a failure and mentions soft-state as a possible implementation choice. 5.4.1 Mutability information on parameters: states that an NI needs to be able to control the mutability of NSIS parameters 5.7.5 Hop-by-hop security: states that intermediate nodes may be modifying the message. None of these sections preclude or mandate an NF to request a reservation. The ability to initiate a reservation at the NF is potentially useful in case of failures. In that case, the NF can request a reservation on an alternative path on behalf of the NI which reduces the potential service interruption. The first bullet (request reservation) in section 3.3.2 was meant to initiate the discussion on that. The ability to modify a message is clearly desirable at each of the NEs. It is, however, not the same thing as modifying the reservation. Modifying a reservation would mean taking the decision to reserve less (or more) resources. It is not clear that either an NF or an NR would be allowed to do that. The requirements document talks about control of mutability here but only as a SHOULD (not MUST). I am not sure what happens when an implementation chooses not to implement this. I think we saw changing the reservation request at intermediate nodes as no more than an optimisation which could save set-up delay. I am not sure if this is worth the additional complexity. Hence the discussion point in 3.3.2. The requirements only refer to the possibility for automatic release of resources after a failure. I am not sure if this covers cases where the release is due to other issues. The requirements do not state that this means that the NF would say 'initiating a reservation teardown' rather than 'releasing a reservation'. An NF could then send a notification to the NI which would initiate the teardown. Does any of this address your comment? Cheers, Sven. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 11:40: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 LAA21753 for ; Mon, 4 Nov 2002 11:40:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4GgLC05669 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 11:42:21 -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 gA4GgIv05660; Mon, 4 Nov 2002 11:42: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 gA4Gfmv05617 for ; Mon, 4 Nov 2002 11:41:48 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21697 for ; Mon, 4 Nov 2002 11:39:16 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA4Gfea21122; Mon, 4 Nov 2002 08:41:40 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id QAA03929; Mon, 4 Nov 2002 16:41:40 GMT Date: Mon, 4 Nov 2002 16:41:40 GMT Message-Id: <200211041641.QAA03929@gra.isi.edu> To: nsis@ietf.org, brunner@ccrle.nec.de Subject: Re: [NSIS] Comments on requirements draft X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> >References need to be split into normative and informative *> *> there are no non-normative references Marcus, Actually, this normative business is a little confusing for everybody. From the viewpoint of the RFC Editor, the normative attribute is really relevant only on standards track documents (or BCPs, which are quasi-standards). Since this is a requirements draft that will not be a standard of any kind, some believe that NONE of its references need be normative. The practical consequence of a normative reference is that it may hold up publication if the referenced document has not itself been published. Mutual normative references force a group of RFCs to be published simultaneously, often holding them all up because due to a minor glitch in one of them. If the referenced documet is already published, making a normative reference to it has no practical consequences. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 11:49: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 LAA21999 for ; Mon, 4 Nov 2002 11:49:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4Gp7t06074 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 11:51: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 gA4Gp5v06066; Mon, 4 Nov 2002 11:51: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 gA4Gosv06044 for ; Mon, 4 Nov 2002 11:50:54 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21987 for ; Mon, 4 Nov 2002 11:48:23 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA4Gooa27389; Mon, 4 Nov 2002 08:50:50 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id QAA03957; Mon, 4 Nov 2002 16:50:50 GMT Date: Mon, 4 Nov 2002 16:50:50 GMT Message-Id: <200211041650.QAA03957@gra.isi.edu> To: Ruediger.Geib@t-systems.com, john.loughney@nokia.com Subject: RE: nsis mobility interactions (was: RE: [NSIS] Some comments on draft-ietf-nsis-req-04.txt) Cc: nsis@ietf.org X-Sun-Charset: ISO-8859-1 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> Hi Rüdiger, *> *> What I take from Bob's mail is that an NSIS protocol may wish may, or may not... it is an open technical question that needs thought and debate. RSVP did not need such a process, so there is precedent for the CON side. The PRO sides needs to provide some convincing examples of where explicit neighbor discovery is needed. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 12:10: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 MAA22844 for ; Mon, 4 Nov 2002 12:10:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4HC8d07977 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 12:12: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 gA4HC6v07961; Mon, 4 Nov 2002 12: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 gA4HBOv07886 for ; Mon, 4 Nov 2002 12:11:25 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22751 for ; Mon, 4 Nov 2002 12:08:52 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gA4HBJi23972; Mon, 4 Nov 2002 18:11:19 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gA4HBJm14357; Mon, 4 Nov 2002 18:11:19 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: , , Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-threats-00.txt Date: Mon, 4 Nov 2002 18:11:44 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi john, hi marcus the next version of the document will have the title: "Security Threats in Signaling". please send me comments to the described threats (or additional threats). a new document version will be available shortly after the next ietf meeting. the updates are mainly editorial to improve the readability of the draft. ciao hannes > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > john.loughney@nokia.com > Sent: Monday, November 04, 2002 9:49 AM > To: brunner@ccrle.nec.de; nsis@ietf.org > Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-threats-00.txt > > > Hi Marcus, > > I think you suggestions are reasonable. > > John > > > -----Original Message----- > > From: ext Marcus Brunner [mailto:brunner@ccrle.nec.de] > > Sent: 01 November, 2002 21:27 > > To: nsis@ietf.org > > Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-threats-00.txt > > > > > > IMHO it should be titled "Signaling Security Threats" or > > "Security Threats in Signaling" > > > > Marcus > > > > --On Freitag, 1. November 2002 08:43 -0500 > > Internet-Drafts@ietf.org wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. This draft is a work item of the Next Steps in > > Signaling > > > Working Group of the IETF. > > > > > > Title : NSIS Threats > > > Author(s) : H. Tschofenig > > > Filename : draft-ietf-nsis-threats-00.txt > > > Pages : 15 > > > Date : 2002-10-31 > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 12:10: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 MAA22859 for ; Mon, 4 Nov 2002 12:10:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4HCBa08016 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 12:12: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 gA4HC9v07991; Mon, 4 Nov 2002 12:12: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 gA4HBPv07890 for ; Mon, 4 Nov 2002 12:11:25 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22753 for ; Mon, 4 Nov 2002 12:08:53 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gA4HBKi23981; Mon, 4 Nov 2002 18:11:20 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gA4HBJm14366; Mon, 4 Nov 2002 18:11:19 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: , Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation identifier Date: Mon, 4 Nov 2002 18:11:44 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <18452713.1036193599@[192.168.102.207]> Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi marcus i hope that i am not fully misunderstanding something but it had the impression that this concept was agreed by everyone. even the framework says that the separation of a reservation (or session) identifier and the flow identifier is important to address mobility issues. ciao hannes > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Marcus Brunner > Sent: Friday, November 01, 2002 11:33 PM > To: nsis@ietf.org > Subject: [NSIS] Req-Draft: Open Issue 2: Independence of reservation > identifier > > > > Req-Draft: Open Issue 2: Independence of reservation identifier > ---------------------------------------------------- > > - see thread on NSIS and mobility > - is the req needed? > - is it needed for a general NSIS base protocol? Or is it application > dependent? > > 5.4.3 Independence of reservation identifier > > A reservation identifier MUST be independent of the flow identifier (flow > end-points). Various scenarios in the mobility area require this > independence because flows resulting from handoff might have changed > end-points etc. but still have the same service requirement. Also several > proxy-based signaling methods profit from such as independence. > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > personal home page: http://www.brubers.org/marcus > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 12:10: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 MAA22870 for ; Mon, 4 Nov 2002 12:10:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4HCCt08047 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 12:12: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 gA4HCAv08006; Mon, 4 Nov 2002 12:12: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 gA4HBPv07892 for ; Mon, 4 Nov 2002 12:11:25 -0500 Received: from thoth.sbs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22756 for ; Mon, 4 Nov 2002 12:08:53 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id gA4HBKW05307; Mon, 4 Nov 2002 18:11:20 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gA4HBKm14373; Mon, 4 Nov 2002 18:11:20 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: , Subject: RE: [NSIS] Req-Draft: Open Issue 3: Replay protection Date: Mon, 4 Nov 2002 18:11:45 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <18480473.1036193627@[192.168.102.207]> Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi markus! my observation is that replay protection should be classified as a MUST. i am not aware of a protocol which suggests to classify it as a should. furthermore replay protection is stronly related to authentication. if you have no guarantee of freshness then proper authentication is also hard to achieve. ciao hannes > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Marcus Brunner > Sent: Friday, November 01, 2002 11:34 PM > To: nsis@ietf.org > Subject: [NSIS] Req-Draft: Open Issue 3: Replay protection > > > Req-Draft: Open Issue 3: Replay protection > ------------------------------- > > Is req 5.7.4 a MUST or SHOULD > SHOULD because it is too complicated to do > > 5.7.4 Replay protection > > To prevent replay of previous signaling messages the signaling protocol > MUST provide means to detect old i.e. already transmitted signaling > messages. A solution must cover issues of synchronization problems in the > case of a restart or a crash of a participating network element. > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > personal home page: http://www.brubers.org/marcus > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 12:10: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 MAA22887 for ; Mon, 4 Nov 2002 12:10:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4HCEJ08073 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 12:12: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 gA4HCBv08034; Mon, 4 Nov 2002 12:12: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 gA4HBQv07898 for ; Mon, 4 Nov 2002 12:11:26 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22758 for ; Mon, 4 Nov 2002 12:08:53 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id gA4HBKK17086; Mon, 4 Nov 2002 18:11:21 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gA4HBKm14384; Mon, 4 Nov 2002 18:11:20 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: , Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Date: Mon, 4 Nov 2002 18:11:45 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <18580787.1036193727@[192.168.102.207]> Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi marcus i would agree to a stronger requirement for confidentiality protection of signaling messages. how about: "NSIS signaling messages MUST be confidentiality protected between NSIS nodes." ciao hannes > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Marcus Brunner > Sent: Friday, November 01, 2002 11:35 PM > To: nsis@ietf.org > Subject: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling > messages > > > > Req-Draft: Open Issue 4: Confidentiality of signaling messages > --------------------------------------------------- > > Proposal to change Req 5.7.8 > "The NSIS protocol MUST allow encryption of NSIS messages between NSIS > nodes." > > Currently it says > > 5.7.8 Confidentiality of signaling messages > > Based on the signaling information exchanged between nodes > participating in > the signaling protocol an adversary may learn both the identities and the > content of the signaling messages. To prevent this from happening, > confidentiality of the signaling message in a hop-by-hop manner MAY be > provided. Note that the protection can be provided on a hop-by-hop basis > for most message payloads since it is required that entities > which actively > participating in the signaling protocol must be able to read and > eventually > modify the content of the signaling messages." > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > personal home page: http://www.brubers.org/marcus > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 12:10: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 MAA22900 for ; Mon, 4 Nov 2002 12:10:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4HCF108089 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 12:12:15 -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 gA4HCDv08061; Mon, 4 Nov 2002 12:12: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 gA4HBQv07900 for ; Mon, 4 Nov 2002 12:11:26 -0500 Received: from thoth.sbs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22759 for ; Mon, 4 Nov 2002 12:08:53 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id gA4HBLW05312; Mon, 4 Nov 2002 18:11:21 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gA4HBLm14395; Mon, 4 Nov 2002 18:11:21 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: , Subject: RE: [NSIS] Req-Draft: Open Issue 5 Req 5.7.10 Hooks ... Date: Mon, 4 Nov 2002 18:11:45 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <18700299.1036193846@[192.168.102.207]> Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi marcus i think that nsis should be able to interact with other protocols (called hooks in this context). other protocols also require such interaction. to make sure that the interaction is actually possible (and that it works in the expected way) a requirement should be specified. is the descripion too fuzzy? should it simply be discussed in the framework only? ciao hannes > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Marcus Brunner > Sent: Friday, November 01, 2002 11:37 PM > To: nsis@ietf.org > Subject: [NSIS] Req-Draft: Open Issue 5 Req 5.7.10 Hooks ... > > > Req-Draft: Open Issue 5 Req 5.7.10 Hooks ... > -------------------------------------------- > > Proposal to remove req 5.7.10 " Hooks with Authentication and Key > Agreement > protocols" > > 5.7.10 Hooks with Authentication and Key Agreement protocols > > This requirement covers two subsequent steps before a signaling > protocol is > executed and the required hooks. First there is a need to agree on a > specific authentication protocol. Later this protocol is executed and > provides authentication and establishes the desired security > associations. > Using these security associations it is then possible to exchange secured > signaling messages. > > The signaling protocol implementation SHOULD provide hooks to > interact with > protocols that allow the negotiation of authentication and key agreement > protocols. Although the negotiation of an authentication and key > management > protocol within the signaling protocol may be outside the scope > it is still > required to trigger this exchange in case that no such security > association > is available. > This requirement originates from the fact that more than one key > management > protocol may be used to provide a security association for the signaling > protocol. Hence the communicating entities must be capable to agree on a > specific authentication. The selected authentication and key agreement > protocol must however be able to create a security association > that can be > used within the signaling protocol. > > Key management protocols typically require a larger number of messages to > be transmitted to allow a session key and the corresponding security > association to be derived. To avoid the complex issue of embedding > individual authentication and key agreement protocols into a specific > signaling protocol it is required that most of these protocols > are executed > independently (prior to the signaling protocol) and although the key > management protocol may be independent there must be a way for the > signaling protocol to access and use available (i.e. already established) > security associations to avoid executing a separate key > management protocol > (or instance of the same protocol) for protocols that closely operate > together. If no such security association exists then there > SHOULD be means > for the signaling protocol to dynamically trigger such a protocol. > > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > personal home page: http://www.brubers.org/marcus > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 12:23: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 MAA23413 for ; Mon, 4 Nov 2002 12:23:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4HPDK08500 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 12:25: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 gA4HPAv08472; Mon, 4 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 gA4HOrv08434 for ; Mon, 4 Nov 2002 12:24:53 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23388 for ; Mon, 4 Nov 2002 12:22:22 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA4HOma23412 for ; Mon, 4 Nov 2002 09:24:48 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id RAA04030 for nsis@ietf.org; Mon, 4 Nov 2002 17:24:48 GMT Date: Mon, 4 Nov 2002 17:24:48 GMT Message-Id: <200211041724.RAA04030@gra.isi.edu> To: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation identifier X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> hi marcus *> *> i hope that i am not fully misunderstanding something but it had the *> impression that this concept was agreed by everyone. even the framework says *> that the separation of a reservation (or session) identifier and the flow *> identifier is important to address mobility issues. *> *> ciao *> hannes *> *> I believe we had considerable discussion on this point, and I don't think a final agreement was reached. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 12:24: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 MAA23466 for ; Mon, 4 Nov 2002 12:24:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4HQ6i08560 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 12:26: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 gA4HQ2v08551; Mon, 4 Nov 2002 12:26: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 gA4HPlv08536 for ; Mon, 4 Nov 2002 12:25:47 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23428 for ; Mon, 4 Nov 2002 12:23:16 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA4HPga24088 for ; Mon, 4 Nov 2002 09:25:42 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id RAA04033 for nsis@ietf.org; Mon, 4 Nov 2002 17:25:42 GMT Date: Mon, 4 Nov 2002 17:25:42 GMT Message-Id: <200211041725.RAA04033@gra.isi.edu> To: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> hi marcus *> *> i would agree to a stronger requirement for confidentiality protection of *> signaling messages. *> *> how about: *> *> "NSIS signaling messages MUST be confidentiality protected between NSIS *> nodes." *> *> ciao *> hannes *> *> Whoa!!! Strong encryption has a cost, and it is by no means clear that very many users of your protocol are going to want or need to pay that cost in order to protect confidentiality of signaling. Your version shifts from a requirement for support, which was reasonable, to a requirement for implementation and use, which is out of bounds. Bob Braden *> > -----Original Message----- *> > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of *> > Marcus Brunner *> > Sent: Friday, November 01, 2002 11:35 PM *> > To: nsis@ietf.org *> > Subject: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling *> > messages *> > *> > *> > *> > Req-Draft: Open Issue 4: Confidentiality of signaling messages *> > --------------------------------------------------- *> > *> > Proposal to change Req 5.7.8 *> > "The NSIS protocol MUST allow encryption of NSIS messages between NSIS *> > nodes." *> > *> > Currently it says *> > *> > 5.7.8 Confidentiality of signaling messages *> > *> > Based on the signaling information exchanged between nodes *> > participating in *> > the signaling protocol an adversary may learn both the identities and the *> > content of the signaling messages. To prevent this from happening, *> > confidentiality of the signaling message in a hop-by-hop manner MAY be *> > provided. Note that the protection can be provided on a hop-by-hop basis *> > for most message payloads since it is required that entities *> > which actively *> > participating in the signaling protocol must be able to read and *> > eventually *> > modify the content of the signaling messages." *> > *> > -------------------------------------- *> > Dr. Marcus Brunner *> > Network Laboratories *> > NEC Europe Ltd. *> > *> > E-Mail: brunner@ccrle.nec.de *> > WWW: http://www.ccrle.nec.de/ *> > Phone: +49 (0) 6221 905 11 29 *> > personal home page: http://www.brubers.org/marcus *> > *> > *> > _______________________________________________ *> > nsis mailing list *> > nsis@ietf.org *> > https://www1.ietf.org/mailman/listinfo/nsis *> *> _______________________________________________ *> nsis mailing list *> nsis@ietf.org *> https://www1.ietf.org/mailman/listinfo/nsis *> ----- End Included Message ----- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 12:31: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 MAA23954 for ; Mon, 4 Nov 2002 12:31:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4HX8D08977 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 12:33: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 gA4HX6v08962; Mon, 4 Nov 2002 12:33: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 gA4HW5v08900 for ; Mon, 4 Nov 2002 12:32:05 -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 MAA23876 for ; Mon, 4 Nov 2002 12:29: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 gA4HVxot011246; Mon, 4 Nov 2002 09:31:59 -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 AAQ93336; Mon, 4 Nov 2002 09:27:13 -0800 (PST) Message-Id: <200211041727.AAQ93336@mira-sjc5-4.cisco.com> To: Bob Braden cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages In-Reply-To: Message from Bob Braden of "Mon, 04 Nov 2002 17:25:42 GMT." <200211041725.RAA04033@gra.isi.edu> Date: Mon, 04 Nov 2002 12:31:57 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > Whoa!!! Strong encryption has a cost, and it is by no means clear that > very many users of your protocol are going to want or need to pay that > cost in order to protect confidentiality of signaling. Your version > shifts from a requirement for support, which was reasonable, to > a requirement for implementation and use, which is out of bounds. It's also very common for protocols to require encryption without saying much, if anything, about keying, and keying is where things go to heck in a handbasket very, very quickly. If we're going to require that NSIS entities in two different domains are going to be able to establish a security association between them, we need to think long and hard about where the keys are going to come from. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 12:53: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 MAA25366 for ; Mon, 4 Nov 2002 12:53:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4HtJr10714 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 12:55:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4HtHv10707; Mon, 4 Nov 2002 12:55: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 gA4Hs3v10651 for ; Mon, 4 Nov 2002 12:54:03 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25273 for ; Mon, 4 Nov 2002 12:51:32 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA4Hrua15890; Mon, 4 Nov 2002 09:53:56 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id RAA04098; Mon, 4 Nov 2002 17:53:55 GMT Date: Mon, 4 Nov 2002 17:53:55 GMT Message-Id: <200211041753.RAA04098@gra.isi.edu> To: nsis@ietf.org, brunner@ccrle.nec.de Subject: Re: [NSIS] Req-Draft: Open Issue 2: Independence of reservation identifier X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> *> Req-Draft: Open Issue 2: Independence of reservation identifier *> ---------------------------------------------------- *> *> - see thread on NSIS and mobility *> - is the req needed? *> - is it needed for a general NSIS base protocol? Or is it application *> dependent? *> *> 5.4.3 Independence of reservation identifier *> *> A reservation identifier MUST be independent of the flow identifier (flow Actually, only trouble I have with this statement is capitalizing MUST. By its very definition, a reservation identifier is independent of the flow identifier (otherwise, we wouldn't call it a reservation identifier, we would call it a flow identifier, right?) Since the independence is by definition, not de jure, there is no place for MUST here -- there is no requirement. The requirement (should it be agreed upon), woudd simply be that the protocol MUST support a reservation identifier. HINT: The best list of requirements is the shortest list, not the longest list. Bob Braden *> end-points). Various scenarios in the mobility area require this *> independence because flows resulting from handoff might have changed *> end-points etc. but still have the same service requirement. Also several *> proxy-based signaling methods profit from such as independence. *> *> *> -------------------------------------- *> Dr. Marcus Brunner *> Network Laboratories *> NEC Europe Ltd. *> *> E-Mail: brunner@ccrle.nec.de *> WWW: http://www.ccrle.nec.de/ *> Phone: +49 (0) 6221 905 11 29 *> personal home page: http://www.brubers.org/marcus *> *> *> _______________________________________________ *> nsis mailing list *> nsis@ietf.org *> https://www1.ietf.org/mailman/listinfo/nsis *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 12:54: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 MAA25425 for ; Mon, 4 Nov 2002 12:54:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4Hu4w10765 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 12:56: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 gA4Hu2v10757; Mon, 4 Nov 2002 12:56: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 gA4Htuv10742 for ; Mon, 4 Nov 2002 12:55:56 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25382 for ; Mon, 4 Nov 2002 12:53:25 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA4Htma17246; Mon, 4 Nov 2002 09:55:48 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id RAA04113; Mon, 4 Nov 2002 17:55:48 GMT Date: Mon, 4 Nov 2002 17:55:48 GMT Message-Id: <200211041755.RAA04113@gra.isi.edu> To: nsis@ietf.org, brunner@ccrle.nec.de Subject: Re: [NSIS] Req-Draft: Open Issue 3: Replay protection X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> From nsis-admin@ietf.org Fri Nov 1 14:35:05 2002 *> Date: Fri, 01 Nov 2002 23:33:47 +0100 *> From: Marcus Brunner *> To: nsis@ietf.org *> MIME-Version: 1.0 *> Content-Transfer-Encoding: 7bit *> Content-Disposition: inline *> Content-Transfer-Encoding: 7bit *> Subject: [NSIS] Req-Draft: Open Issue 3: Replay protection *> X-BeenThere: nsis@ietf.org *> X-Mailman-Version: 2.0.12 *> List-Unsubscribe: , *> *> List-Id: Next Steps in Signaling *> List-Post: *> List-Help: *> List-Subscribe: , *> *> X-AntiVirus: scanned by AMaViS 0.2.1 *> *> Req-Draft: Open Issue 3: Replay protection *> ------------------------------- *> *> Is req 5.7.4 a MUST or SHOULD *> SHOULD because it is too complicated to do *> Not clear that it is too complicated... the RSVP hop/hop security mechanism has replay protection, and the algorithm is already documented in an RFC. Bob Braden *> 5.7.4 Replay protection *> *> To prevent replay of previous signaling messages the signaling protocol *> MUST provide means to detect old i.e. already transmitted signaling *> messages. A solution must cover issues of synchronization problems in the *> case of a restart or a crash of a participating network element. *> *> *> -------------------------------------- *> Dr. Marcus Brunner *> Network Laboratories *> NEC Europe Ltd. *> *> E-Mail: brunner@ccrle.nec.de *> WWW: http://www.ccrle.nec.de/ *> Phone: +49 (0) 6221 905 11 29 *> personal home page: http://www.brubers.org/marcus *> *> *> _______________________________________________ *> nsis mailing list *> nsis@ietf.org *> https://www1.ietf.org/mailman/listinfo/nsis *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 12:58: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 MAA25714 for ; Mon, 4 Nov 2002 12:58:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4I09G10983 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 13:00:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4I07v10976; Mon, 4 Nov 2002 13:00: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 gA4HxZv10922 for ; Mon, 4 Nov 2002 12:59:35 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25642 for ; Mon, 4 Nov 2002 12:57:04 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA4HxRa20699; Mon, 4 Nov 2002 09:59:27 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id RAA04116; Mon, 4 Nov 2002 17:59:27 GMT Date: Mon, 4 Nov 2002 17:59:27 GMT Message-Id: <200211041759.RAA04116@gra.isi.edu> To: nsis@ietf.org, brunner@ccrle.nec.de Subject: Re: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> *> Req-Draft: Open Issue 4: Confidentiality of signaling messages *> --------------------------------------------------- *> *> Proposal to change Req 5.7.8 *> "The NSIS protocol MUST allow encryption of NSIS messages between NSIS *> nodes." *> Marcus, I suspect that this is what "MAY be provided" was intended to mean, but I agree that your proposed restatemnt is much clearer, and I support it. Bob Braden *> Currently it says *> *> 5.7.8 Confidentiality of signaling messages *> *> Based on the signaling information exchanged between nodes participating in *> the signaling protocol an adversary may learn both the identities and the *> content of the signaling messages. To prevent this from happening, *> confidentiality of the signaling message in a hop-by-hop manner MAY be *> provided. Note that the protection can be provided on a hop-by-hop basis *> for most message payloads since it is required that entities which actively *> participating in the signaling protocol must be able to read and eventually *> modify the content of the signaling messages." *> *> -------------------------------------- *> Dr. Marcus Brunner *> Network Laboratories *> NEC Europe Ltd. *> *> E-Mail: brunner@ccrle.nec.de *> WWW: http://www.ccrle.nec.de/ *> Phone: +49 (0) 6221 905 11 29 *> personal home page: http://www.brubers.org/marcus *> *> *> _______________________________________________ *> nsis mailing list *> nsis@ietf.org *> https://www1.ietf.org/mailman/listinfo/nsis *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 14:19: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 OAA00401 for ; Mon, 4 Nov 2002 14:19:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4JLKQ16641 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 14:21: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 gA4JLIv16634; Mon, 4 Nov 2002 14:21: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 gA4JKsv16601 for ; Mon, 4 Nov 2002 14:20:54 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00322 for ; Mon, 4 Nov 2002 14:18:22 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Nov 2002 19:20:48 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5D22@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Bob Braden , nsis@ietf.org, brunner@ccrle.nec.de Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Mon, 4 Nov 2002 19:20:38 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all, I confess being somewhat in a dilemma about this one. Please excuse the following somewhat discursive email. On the one hand, I think there is (fairly) widespread consensus that an independent reservation identifier is needed to support certain seamless mobility functions. For example, Mike Thomas' draft includes in 1.2.5: "... this draft makes the wild and perhaps unfounded assumption that the ISSLL working group will step up to allowing RSVP to use a session identifier in addition to the normal 5-tuple to identify a reservation. Given the round trip implications, the author cannot see how seamless mobility with RSVP reservations can be achieved if this assumption is false." What is unclear is (a) whether the improvements over plain resignalling from scratch is worth it (b) especially given that supporting such an identifier is hard. But in any case, if the role of this identifier is supporting mobility scenarios, then we already have a requirement for that (5.8.1, "Allow efficient XXX re-establishment after handover"). If a separate identifier is the only way to meet that, we'll get it anyway. Incidentally, if we delete 'efficient' in 5.8.1 the requirement becomes unambiguous and entirely vacuous, since you can always resignal from scratch. In that sense, we don't need 5.4.3.... On the other hand, we have (I think) a general goal to develop something that can be used for applications and in scenarios we haven't thought of yet, which leads to certain goals about modularity, clean interfaces with other protocols/functions, and so on. Being able to refer to a reservation independently of the flow identification could come into that category of Good Things (like, for example, structuring things as two layers/levels...). But does that mean we need it in the requirements document? It depends what you want to use the requirements document for (which actually isn't clear to me at the moment). My instinctual preference would be to keep it as a should. Cheers, Robert H. > -----Original Message----- > From: Bob Braden [mailto:braden@ISI.EDU] > Sent: 04 November 2002 17:54 > To: nsis@ietf.org; brunner@ccrle.nec.de > Subject: Re: [NSIS] Req-Draft: Open Issue 2: Independence of > reservation > identifier > > > > *> > *> > *> Req-Draft: Open Issue 2: Independence of reservation identifier > *> ---------------------------------------------------- > *> > *> - see thread on NSIS and mobility > *> - is the req needed? > *> - is it needed for a general NSIS base protocol? Or is > it application > *> dependent? > *> > *> 5.4.3 Independence of reservation identifier > *> > *> A reservation identifier MUST be independent of the flow > identifier (flow > > Actually, only trouble I have with this statement is capitalizing > MUST. By its very definition, a reservation identifier is independent > of the flow identifier (otherwise, we wouldn't call it a reservation > identifier, we would call it a flow identifier, right?) Since the > independence is by definition, not de jure, there is no place for MUST > here -- there is no requirement. The requirement (should it be agreed > upon), woudd simply be that the protocol MUST support a reservation > identifier. > > HINT: The best list of requirements is the shortest list, not the > longest list. > > Bob Braden > > *> end-points). Various scenarios in the mobility area require this > *> independence because flows resulting from handoff might > have changed > *> end-points etc. but still have the same service > requirement. Also several > *> proxy-based signaling methods profit from such as independence. > *> > *> > *> -------------------------------------- > *> Dr. Marcus Brunner > *> Network Laboratories > *> NEC Europe Ltd. > *> > *> E-Mail: brunner@ccrle.nec.de > *> WWW: http://www.ccrle.nec.de/ > *> Phone: +49 (0) 6221 905 11 29 > *> personal home page: http://www.brubers.org/marcus > *> > *> > *> _______________________________________________ > *> nsis mailing list > *> nsis@ietf.org > *> https://www1.ietf.org/mailman/listinfo/nsis > *> > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 14:33: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 OAA01633 for ; Mon, 4 Nov 2002 14:33:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4JZ8u17639 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 14:35: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 gA4JZ5v17631; Mon, 4 Nov 2002 14:35: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 gA4JY7v17552 for ; Mon, 4 Nov 2002 14:34:07 -0500 Received: from idcpa4.pa.interdigital.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01535 for ; Mon, 4 Nov 2002 14:31:35 -0500 (EST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Nov 2002 14:32:56 -0500 Message-ID: <5238EB1F9A88D8499B8610F4BEEF46F726A93B@PAEX2000.InterDigital.com> From: "Shaheen, Kamel M." To: nsis@ietf.org Subject: [NSIS] I-D draft-Shaheen-nsis-brsvp-00.txt Date: Mon, 4 Nov 2002 14:33:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , ftp://ietf.org/internet-drafts/draft-shaheen-shahrier-nsis-brsvp-00.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 14:58: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 OAA03404 for ; Mon, 4 Nov 2002 14:58:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4K0Px19577 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 15:00: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 gA4K0Mv19550; Mon, 4 Nov 2002 15:00: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 gA4Jwhv19414 for ; Mon, 4 Nov 2002 14:58:43 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03266 for ; Mon, 4 Nov 2002 14:56:10 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA4JwVa15333; Mon, 4 Nov 2002 11:58:31 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id TAA04204; Mon, 4 Nov 2002 19:58:31 GMT Date: Mon, 4 Nov 2002 19:58:31 GMT Message-Id: <200211041958.TAA04204@gra.isi.edu> To: braden@ISI.EDU, nsis@ietf.org, brunner@ccrle.nec.de, robert.hancock@roke.co.uk Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> On the one hand, I think there is (fairly) widespread consensus that an independent reservation identifier is needed to support certain seamless mobility functions. For example, Mike Thomas' draft includes in 1.2.5: Robert, "Widespread consensus" does not always mean it's true ;-). Ten years ago there were countless papers and publications citing the "widespread consensus" that TCP could never be made to operate faster than a megabit per second, since TCP was too "heavyweight" a protocol. This of course turned out to be nonsense. *> *> "... this draft makes the wild and perhaps unfounded *> assumption that the ISSLL working group will step up to allowing RSVP *> to use a session identifier in addition to the normal 5-tuple to *> identify a reservation. Given the round trip implications, the author *> cannot see how seamless mobility with RSVP reservations can be *> achieved if this assumption is false." *> *> What is unclear is *> (a) whether the improvements over plain resignalling from scratch is worth it Yes... *> (b) especially given that supporting such an identifier is hard. *> I am puzzled about what is hard about it. It seems pretty straightforward. Is there a one or two-sentence explanation of why it is hard? Bob *> But in any case, if the role of this identifier is supporting mobility scenarios, then we already have a requirement for that (5.8.1, "Allow efficient XXX re-establishment after handover"). If a separate identifier is the only way to meet that, we'll get it anyway. Incidentally, if we delete 'efficient' in 5.8.1 the requirement becomes unambiguous and entirely vacuous, since you can always resignal from scratch. *> *> In that sense, we don't need 5.4.3.... *> *> On the other hand, we have (I think) a general goal to develop something that can be used for applications and in scenarios we haven't thought of yet, which leads to certain goals about modularity, clean interfaces with other protocols/functions, and so on. Being able to refer to a reservation independently of the flow identification could come into that category of Good Things (like, for example, structuring things as two layers/levels...). But does that mean we need it in the requirements document? It depends what you want to use the requirements document for (which actually isn't clear to me at the moment). *> *> My instinctual preference would be to keep it as a should. *> *> Cheers, *> *> Robert H. *> *> > -----Original Message----- *> > From: Bob Braden [mailto:braden@ISI.EDU] *> > Sent: 04 November 2002 17:54 *> > To: nsis@ietf.org; brunner@ccrle.nec.de *> > Subject: Re: [NSIS] Req-Draft: Open Issue 2: Independence of *> > reservation *> > identifier *> > *> > *> > *> > *> *> > *> *> > *> Req-Draft: Open Issue 2: Independence of reservation identifier *> > *> ---------------------------------------------------- *> > *> *> > *> - see thread on NSIS and mobility *> > *> - is the req needed? *> > *> - is it needed for a general NSIS base protocol? Or is *> > it application *> > *> dependent? *> > *> *> > *> 5.4.3 Independence of reservation identifier *> > *> *> > *> A reservation identifier MUST be independent of the flow *> > identifier (flow *> > *> > Actually, only trouble I have with this statement is capitalizing *> > MUST. By its very definition, a reservation identifier is independent *> > of the flow identifier (otherwise, we wouldn't call it a reservation *> > identifier, we would call it a flow identifier, right?) Since the *> > independence is by definition, not de jure, there is no place for MUST *> > here -- there is no requirement. The requirement (should it be agreed *> > upon), woudd simply be that the protocol MUST support a reservation *> > identifier. *> > *> > HINT: The best list of requirements is the shortest list, not the *> > longest list. *> > *> > Bob Braden *> > *> > *> end-points). Various scenarios in the mobility area require this *> > *> independence because flows resulting from handoff might *> > have changed *> > *> end-points etc. but still have the same service *> > requirement. Also several *> > *> proxy-based signaling methods profit from such as independence. *> > *> *> > *> *> > *> -------------------------------------- *> > *> Dr. Marcus Brunner *> > *> Network Laboratories *> > *> NEC Europe Ltd. *> > *> *> > *> E-Mail: brunner@ccrle.nec.de *> > *> WWW: http://www.ccrle.nec.de/ *> > *> Phone: +49 (0) 6221 905 11 29 *> > *> personal home page: http://www.brubers.org/marcus *> > *> *> > *> *> > *> _______________________________________________ *> > *> nsis mailing list *> > *> nsis@ietf.org *> > *> https://www1.ietf.org/mailman/listinfo/nsis *> > *> *> > _______________________________________________ *> > nsis mailing list *> > nsis@ietf.org *> > https://www1.ietf.org/mailman/listinfo/nsis *> > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 14:58: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 OAA03420 for ; Mon, 4 Nov 2002 14:58:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4K0Qq19590 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 15:00: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 gA4K0Ov19566; Mon, 4 Nov 2002 15: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 gA4Jwkv19418 for ; Mon, 4 Nov 2002 14:58:46 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03277 for ; Mon, 4 Nov 2002 14:56:14 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Nov 2002 19:58:39 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5D26@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Melinda Shore , nsis@ietf.org Date: Mon, 4 Nov 2002 19:58:34 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] sender/receiver initiation (was: RE: Comments on framework draft) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Melinda, all, Now all deadlines are passed, some technical responses to your earlier comments. I'm trying to break these up to enable some conversational focus. ['>' = MS] > 4.2 control primitives seem to assume sender-oriented > signaling (para 3). [NB para 2 in -01.txt] > > 4.3.2 depends entirely on whether sender-oriented or > receiver-oriented signaling is used. > Actually, I'm not sure why this impression is given: the basic point is that there is no assumed relationship of NI/NR w.r.t. data sender or receiver. If the NI is at (or near) the sender, 4.2 and 4.3.2 are describing sender-oriented signallng, but not if it is at the receiver. (Maybe it should be emphasised earlier?) Of course, there's a group of *much* bigger questions this relates to: *) Should NSIS concentrate on one (sender/receiver) paradigm or the other? *) Do the concepts of NI/NR relate to the NTLP or NSLPs? (It was even quite hard to update the draft without knowing this.) *) Indeed/alternatively, do the message types (4.3.2) expose themselves in the NTLP or NSLPs? For example, do we know already that for all time, all signalling applications will need the NTLP to send messages which 'request' or 'release' etc. things called 'reservations'? Or should we look at a thinner NTLP which just sends messages along the data path with or against the flow direction? (I think it's instructive to look at the evolution of AAA protocols in this respect.) I don't pretend these are easy questions. Cheers, Robert H. PS: I've tried to summarise some of these issues (and suggest a way forward), in what I hope is a non-partisan, protocol independent i-d, draft-hancock-sender-receiver-00.txt. The main issues seem to be the ones noted above. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 4 15:23: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 PAA04625 for ; Mon, 4 Nov 2002 15:23:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA4KPL021334 for nsis-archive@odin.ietf.org; Mon, 4 Nov 2002 15:25:21 -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 gA4KPHv21327; Mon, 4 Nov 2002 15: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 gA4KORv21286 for ; Mon, 4 Nov 2002 15:24:27 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04571 for ; Mon, 4 Nov 2002 15:21:54 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Nov 2002 20:24:20 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5D27@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Bob Braden , nsis@ietf.org, brunner@ccrle.nec.de Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Mon, 4 Nov 2002 20:24:09 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Bob, > *> (b) especially given that supporting such an identifier is hard. > *> > > I am puzzled about what is hard about it. It seems pretty > straightforward. > Is there a one or two-sentence explanation of why it is hard? > > Bob This is alluded to in the framework draft (5.3.1/5.3.2, also 4.5.2). The hard point is the security aspect, since so far as I can tell, (in general) any random node in the Internet could pop up and say "I want to modify reservation XXX 'cos it's really mine", and it would be hard to decide whether it wasn't just the real node having moved. All it has to do is get it's signalling message to intersect the existing path for that reservation id. (I can also imagine identifier scoping issues needing careful analysis). There's an interesting proposal in draft-westphal-nsis-qos-mobileip-00.txt, but it requires a fair amount of public-key-like activity per message. By 'hard' I mean 'not impossible, but not easy'. It may be that a sufficiently careful threat analysis would prove the security problems were illusory, but no-one has done that yet. Cheers, Robert PS I'm aware that widespread consensus !==> truth. However, I'm working on the assumption that we can proceed on the basis of consensus rather than proven truth, else progress is liable to be slow ;-). _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 01:51: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 BAA25811 for ; Tue, 5 Nov 2002 01:51:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA56raZ07538 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 01:53: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 gA56rXv07531; Tue, 5 Nov 2002 01:53: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 gA56q5v07482 for ; Tue, 5 Nov 2002 01:52:05 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25791 for ; Tue, 5 Nov 2002 01:49:28 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA56qMB10294 for ; Tue, 5 Nov 2002 08:52:22 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Nov 2002 08:51:54 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 08:51:53 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 08:51:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Req-Draft: Open Issue 3: Replay protection Date: Tue, 5 Nov 2002 08:51:52 +0200 Message-ID: Thread-Topic: [NSIS] Req-Draft: Open Issue 3: Replay protection Thread-Index: AcKEJVakEJdghcbkRO6ffsjPuzIpxgAcmsJg To: , , X-OriginalArrivalTime: 05 Nov 2002 06:51:53.0433 (UTC) FILETIME=[D2FA1C90:01C28497] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA56q5v07483 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, > my observation is that replay protection should be classified > as a MUST. i > am not aware of a protocol which suggests to classify it as a should. > furthermore replay protection is stronly related to > authentication. if you > have no guarantee of freshness then proper authentication is > also hard to achieve. Agree. Additionally, mechanisms to provide replay protection usually are not too heavy to engineer. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 01:51: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 BAA25829 for ; Tue, 5 Nov 2002 01:51:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA56s3i07581 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 01:54: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 gA56s1v07574; Tue, 5 Nov 2002 01:54: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 gA56rbv07550 for ; Tue, 5 Nov 2002 01:53:37 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25803 for ; Tue, 5 Nov 2002 01:51:00 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA56qxO24151 for ; Tue, 5 Nov 2002 08:53:00 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Nov 2002 08:53:26 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 08:53:26 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 08:53:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Date: Tue, 5 Nov 2002 08:53:25 +0200 Message-ID: Thread-Topic: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Thread-Index: AcKEJVfai2Rj/UYZQYCQpC25lQcIfwAcoWrA To: , , X-OriginalArrivalTime: 05 Nov 2002 06:53:25.0612 (UTC) FILETIME=[09EB82C0:01C28498] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA56rbv07551 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Hannes, > i would agree to a stronger requirement for confidentiality > protection of signaling messages. > > how about: > > "NSIS signaling messages MUST be confidentiality protected > between NSIS nodes." Slight tweak: "NSIS signaling messages MUST be possible to be confidentiality ^^^^^^^^^^^^^^ protected between NSIS nodes." John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 01:55: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 BAA25893 for ; Tue, 5 Nov 2002 01:55:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA56v7s07722 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 01:57: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 gA56v4v07701; Tue, 5 Nov 2002 01:57: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 gA56uKv07671 for ; Tue, 5 Nov 2002 01:56:20 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25871 for ; Tue, 5 Nov 2002 01:53:42 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA56uaB13549 for ; Tue, 5 Nov 2002 08:56:36 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Nov 2002 08:56:08 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 08:56:08 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 08:56:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Date: Tue, 5 Nov 2002 08:56:07 +0200 Message-ID: Thread-Topic: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Thread-Index: AcKEKEQFZNH1+VJUSCanBQsUrP8RGwAb+ZJA To: , Cc: X-OriginalArrivalTime: 05 Nov 2002 06:56:08.0393 (UTC) FILETIME=[6AF1EB90:01C28498] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA56uKv07672 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Melinda, > It's also very common for protocols to require encryption > without saying much, if anything, about keying, and keying > is where things go to heck in a handbasket very, very > quickly. If we're going to require that NSIS entities in > two different domains are going to be able to establish a > security association between them, we need to think long and > hard about where the keys are going to come from. So, what would you suggest, as text? I think support for confidentiality is at least a SHOULD, if not a MUST. Additionally requirement could be that key distribution needs to be documented by any solution using encryption. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 02:03: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 CAA00047 for ; Tue, 5 Nov 2002 02:03:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA575AS09263 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 02:05:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5758v09239; Tue, 5 Nov 2002 02: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 gA573xv08302 for ; Tue, 5 Nov 2002 02:03:59 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27764 for ; Tue, 5 Nov 2002 02:01:21 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA574FB20484 for ; Tue, 5 Nov 2002 09:04:15 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Nov 2002 09:03:46 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 09:03:47 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 09:03:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation identifier Date: Tue, 5 Nov 2002 09:03:46 +0200 Message-ID: Thread-Topic: [NSIS] Req-Draft: Open Issue 2: Independence of reservation identifier Thread-Index: AcKEK1ypmJpYMoxOTguv5f2Wy0PjkQAbfbBQ To: , , X-OriginalArrivalTime: 05 Nov 2002 07:03:47.0040 (UTC) FILETIME=[7C51E600:01C28499] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA573xv08303 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Bob, > Actually, only trouble I have with this statement is capitalizing > MUST. By its very definition, a reservation identifier is independent > of the flow identifier (otherwise, we wouldn't call it a reservation > identifier, we would call it a flow identifier, right?) Since the > independence is by definition, not de jure, there is no place for MUST > here -- there is no requirement. The requirement (should it be agreed > upon), woudd simply be that the protocol MUST support a reservation > identifier. > > HINT: The best list of requirements is the shortest list, not the > longest list. I think I agree. It actually also sounds very much like a protocol specific issue. Is the issue really that we would like to have seperation between a reservation & a flow? Perhaps this is one requirement we can drop. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 03:13: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 DAA07172 for ; Tue, 5 Nov 2002 03:13:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA58FHF21834 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 03:15: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 gA58FEv21808; Tue, 5 Nov 2002 03:15: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 gA58EMv21746 for ; Tue, 5 Nov 2002 03:14:22 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07126 for ; Tue, 5 Nov 2002 03:11:43 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 5 Nov 2002 09:13:54 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 09:13:53 +0100 Message-Id: From: "Geib, Ruediger" To: Hannes.Tschofenig@siemens.com Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Date: Tue, 5 Nov 2002 09:13:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA58EMv21749 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hannes, I agree with Bob that encryption of signaling messages is an option, not a requirement. A security mechanism I'd like to see is a digest added to a message. That's message integrity, I assume as non security expert, and therefore another thread. Regards, Rüdiger > i would agree to a stronger requirement for confidentiality > protection of signaling messages. > > how about: > > "NSIS signaling messages MUST be confidentiality protected > between NSIS nodes." > > Req-Draft: Open Issue 4: Confidentiality of signaling messages > > --------------------------------------------------- > > > > Proposal to change Req 5.7.8 > > "The NSIS protocol MUST allow encryption of NSIS messages > between NSIS > > nodes." > > > > Currently it says > > > > 5.7.8 Confidentiality of signaling messages > > > > Based on the signaling information exchanged between nodes > > participating in the signaling protocol an adversary may > > learn both the identities and the content of the signaling > > messages. To prevent this from happening, > > confidentiality of the signaling message in a hop-by-hop > > manner MAY be provided. Note that the protection can be > > provided on a hop-by-hop basis for most message payloads > > since it is required that entities which actively > > participating in the signaling protocol must be able to > > read and eventually > > modify the content of the signaling messages." _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 03:39: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 DAA07570 for ; Tue, 5 Nov 2002 03:39:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA58fVb23565 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 03:41: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 gA58fUv23541; Tue, 5 Nov 2002 03:41:30 -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 gA58Z9v22553 for ; Tue, 5 Nov 2002 03:35:09 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07451 for ; Tue, 5 Nov 2002 03:32:30 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id gA58Yv118138; Tue, 5 Nov 2002 09:34:57 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gA58YvI28972; Tue, 5 Nov 2002 09:34:57 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: , , Cc: Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Date: Tue, 5 Nov 2002 09:35:18 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi i can agree to a requirement which leads people to think about key management. ciao hannes > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > john.loughney@nokia.com > Sent: Tuesday, November 05, 2002 7:56 AM > To: mshore@cisco.com; braden@ISI.EDU > Cc: nsis@ietf.org > Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of > signaling messages > > > Melinda, > > > It's also very common for protocols to require encryption > > without saying much, if anything, about keying, and keying > > is where things go to heck in a handbasket very, very > > quickly. If we're going to require that NSIS entities in > > two different domains are going to be able to establish a > > security association between them, we need to think long and > > hard about where the keys are going to come from. > > So, what would you suggest, as text? > > I think support for confidentiality is at least a SHOULD, if not > a MUST. Additionally requirement could be that key distribution > needs to be documented by any solution using encryption. > > John > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 03:39: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 DAA07587 for ; Tue, 5 Nov 2002 03:39:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA58fZ123596 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 03:41: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 gA58fVv23583; Tue, 5 Nov 2002 03:41: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 gA58Z9v22549 for ; Tue, 5 Nov 2002 03:35:09 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07450 for ; Tue, 5 Nov 2002 03:32:30 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id gA58Yv118136; Tue, 5 Nov 2002 09:34:57 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gA58YuI28957; Tue, 5 Nov 2002 09:34:56 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Melinda Shore" , "Bob Braden" Cc: Date: Tue, 5 Nov 2002 09:35:18 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200211041727.AAQ93336@mira-sjc5-4.cisco.com> Importance: Normal Content-Transfer-Encoding: 7bit Subject: [NSIS] Key management Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi melinda! i agree with you that the key management should be addressed. the question where the keys come from is independent from integrity or confidentiality protection. if signaling messages are not protected then there are obviously some threats. protecting inter-domain signaling messages is also important. i wouldn't like to make QoS reservations (or installing packet filters at my firewall) only because of unauthenticated and unprotected signaling message. the message could basically come from any place in the world. ciao hannes > > > Whoa!!! Strong encryption has a cost, and it is by no means clear that > > very many users of your protocol are going to want or need to pay that > > cost in order to protect confidentiality of signaling. Your version > > shifts from a requirement for support, which was reasonable, to > > a requirement for implementation and use, which is out of bounds. > > It's also very common for protocols to require encryption > without saying much, if anything, about keying, and keying > is where things go to heck in a handbasket very, very > quickly. If we're going to require that NSIS entities in > two different domains are going to be able to establish a > security association between them, we need to think long and > hard about where the keys are going to come from. > > Melinda > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 03:39: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 DAA07600 for ; Tue, 5 Nov 2002 03:39:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA58faY23623 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 03:41: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 gA58fZv23608; Tue, 5 Nov 2002 03:41:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA58ZAv22557 for ; Tue, 5 Nov 2002 03:35:10 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07454 for ; Tue, 5 Nov 2002 03:32:31 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gA58Yvi22159 for ; Tue, 5 Nov 2002 09:34:58 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gA58YvI28987 for ; Tue, 5 Nov 2002 09:34:57 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: Date: Tue, 5 Nov 2002 09:35:19 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Subject: [NSIS] Open Issues: Peer-to-Peer Protection Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi i guess that there is no doubt that a signaling protocol like NSIS must at least offer peer-to-peer protection. it was often mentioned that more than peer-to-peer protection might also be required. should there be a requirement which states something similar? ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 03:39: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 DAA07616 for ; Tue, 5 Nov 2002 03:39:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA58fbA23646 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 03:41: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 gA58fav23637; Tue, 5 Nov 2002 03:41:36 -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 gA58ZAv22561 for ; Tue, 5 Nov 2002 03:35:10 -0500 Received: from thoth.sbs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07455 for ; Tue, 5 Nov 2002 03:32:31 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id gA58YwW24198; Tue, 5 Nov 2002 09:34:58 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gA58YvI28999; Tue, 5 Nov 2002 09:34:57 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Geib, Ruediger" Cc: Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Date: Tue, 5 Nov 2002 09:35:19 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi ruediger. > > Hannes, > > I agree with Bob that encryption of signaling messages > is an option, not a requirement. what i would like to prevent is that a requirement for encryption is so fuzzy that actually nobody applies it their protocol proposals. adding confidentiality protection later to a protocol is often quite difficult. protocol designers should consider it during the initial design. an area where is see a need for confidentiality protection is communication of policy rules (midcom). providing protection against traffic analysis is also a good goal to achieve looking at the increasing importance of privacy issues. > A security mechanism > I'd like to see is a digest added to a message. > That's > message integrity, I assume as non security expert, > and therefore another thread. yes, keyed message digest. ciao hannes > > Regards, Rüdiger > > > i would agree to a stronger requirement for confidentiality > > protection of signaling messages. > > > > how about: > > > > "NSIS signaling messages MUST be confidentiality protected > > between NSIS nodes." > > > > > Req-Draft: Open Issue 4: Confidentiality of signaling messages > > > --------------------------------------------------- > > > > > > Proposal to change Req 5.7.8 > > > "The NSIS protocol MUST allow encryption of NSIS messages > > between NSIS > > > nodes." > > > > > > Currently it says > > > > > > 5.7.8 Confidentiality of signaling messages > > > > > > Based on the signaling information exchanged between nodes > > > participating in the signaling protocol an adversary may > > > learn both the identities and the content of the signaling > > > messages. To prevent this from happening, > > > confidentiality of the signaling message in a hop-by-hop > > > manner MAY be provided. Note that the protection can be > > > provided on a hop-by-hop basis for most message payloads > > > since it is required that entities which actively > > > participating in the signaling protocol must be able to > > > read and eventually > > > modify the content of the signaling messages." > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 03: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 DAA07653 for ; Tue, 5 Nov 2002 03:40:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA58gCu23764 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 03:42: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 gA58gAv23747; Tue, 5 Nov 2002 03:42: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 gA58dJv23365 for ; Tue, 5 Nov 2002 03:39:25 -0500 Received: from thoth.sbs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07505 for ; Tue, 5 Nov 2002 03:36:30 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id gA58cuW26542; Tue, 5 Nov 2002 09:38:56 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gA58ctI02949; Tue, 5 Nov 2002 09:38:55 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: , , , Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation identifier Date: Tue, 5 Nov 2002 09:39:17 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi john. i am not sure that this question is "only" a protocol specific issue. to me it sounds more like a fundamental design decision: do we want mobility support or not. ciao hannes > Hi Bob, > > > Actually, only trouble I have with this statement is capitalizing > > MUST. By its very definition, a reservation identifier is independent > > of the flow identifier (otherwise, we wouldn't call it a reservation > > identifier, we would call it a flow identifier, right?) Since the > > independence is by definition, not de jure, there is no place for MUST > > here -- there is no requirement. The requirement (should it be agreed > > upon), woudd simply be that the protocol MUST support a reservation > > identifier. > > > > HINT: The best list of requirements is the shortest list, not the > > longest list. > > I think I agree. It actually also sounds very much like a protocol > specific issue. Is the issue really that we would like to have seperation > between a reservation & a flow? Perhaps this is one requirement we > can drop. > > John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 03:40: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 DAA07679 for ; Tue, 5 Nov 2002 03:40:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA58gDh23798 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 03:42: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 gA58gCv23793; Tue, 5 Nov 2002 03:42: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 gA58dJv23366 for ; Tue, 5 Nov 2002 03:39:25 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07504 for ; Tue, 5 Nov 2002 03:36:29 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id gA58ct120695; Tue, 5 Nov 2002 09:38:56 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gA58ctI02941; Tue, 5 Nov 2002 09:38:55 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Hancock, Robert" , "Bob Braden" , , Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Tue, 5 Nov 2002 09:39:17 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <76C92FBBFB58D411AE760090271ED41805DF5D27@rsys002a.roke.co.uk> Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi robert. i guess we can say that we looked at the security issues of the reservation/session identifier. this issue was mentioned already long time ago and is included in the nsis requirements doc and in the nsis threats document. since i never got any comment to it i would ask people to tell me their opinion. ciao hannes > > Bob, > > > *> (b) especially given that supporting such an identifier is hard. > > *> > > > > I am puzzled about what is hard about it. It seems pretty > > straightforward. > > Is there a one or two-sentence explanation of why it is hard? > > > > Bob > > This is alluded to in the framework draft (5.3.1/5.3.2, also 4.5.2). > > The hard point is the security aspect, since so far as I can > tell, (in general) any random node in the Internet could pop up > and say "I want to modify reservation XXX 'cos it's really mine", > and it would be hard to decide whether it wasn't just the real > node having moved. All it has to do is get it's signalling > message to intersect the existing path for that reservation id. > > (I can also imagine identifier scoping issues needing careful analysis). > > There's an interesting proposal in > draft-westphal-nsis-qos-mobileip-00.txt, but it requires a fair > amount of public-key-like activity per message. By 'hard' I mean > 'not impossible, but not easy'. It may be that a sufficiently > careful threat analysis would prove the security problems were > illusory, but no-one has done that yet. > > Cheers, > > Robert > > PS I'm aware that widespread consensus !==> truth. However, I'm > working on the assumption that we can proceed on the basis of > consensus rather than proven truth, else progress is liable to be > slow ;-). > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 03:52: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 DAA07947 for ; Tue, 5 Nov 2002 03:52:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA58sRo24425 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 03:54: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 gA58sPv24416; Tue, 5 Nov 2002 03:54: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 gA58rYv24378 for ; Tue, 5 Nov 2002 03:53:34 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07931 for ; Tue, 5 Nov 2002 03:50:55 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 08:53:22 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA698@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Date: Tue, 5 Nov 2002 08:53:13 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA58rZv24379 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, I think there is a general point about several of these requirements, in that at this stage we could be saying (e.g. for a MUST) *) mandatory to SPECIFY in the protocol definition, or *) mandatory to IMPLEMENT in an implementation of it, or *) mandatory to USE in a deployment of an implementation Is it useful to draw this distinction more formally somehow? Or is everything clearly only SPECIFY at this stage (and the rest depends on what the protocol ends up being?) robert h. > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 05 November 2002 08:14 > To: Hannes.Tschofenig@siemens.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of > signaling messages > > > Hannes, > > I agree with Bob that encryption of signaling messages > is an option, not a requirement. A security mechanism > I'd like to see is a digest added to a message. That's > message integrity, I assume as non security expert, > and therefore another thread. > > Regards, Rüdiger > > > i would agree to a stronger requirement for confidentiality > > protection of signaling messages. > > > > how about: > > > > "NSIS signaling messages MUST be confidentiality protected > > between NSIS nodes." > > > > > Req-Draft: Open Issue 4: Confidentiality of signaling messages > > > --------------------------------------------------- > > > > > > Proposal to change Req 5.7.8 > > > "The NSIS protocol MUST allow encryption of NSIS messages > > between NSIS > > > nodes." > > > > > > Currently it says > > > > > > 5.7.8 Confidentiality of signaling messages > > > > > > Based on the signaling information exchanged between nodes > > > participating in the signaling protocol an adversary may > > > learn both the identities and the content of the signaling > > > messages. To prevent this from happening, > > > confidentiality of the signaling message in a hop-by-hop > > > manner MAY be provided. Note that the protection can be > > > provided on a hop-by-hop basis for most message payloads > > > since it is required that entities which actively > > > participating in the signaling protocol must be able to > > > read and eventually > > > modify the content of the signaling messages." > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 03:53: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 DAA07970 for ; Tue, 5 Nov 2002 03:53:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA58u5224527 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 03:56:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA58u4v24520; Tue, 5 Nov 2002 03: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 gA58tcv24471 for ; Tue, 5 Nov 2002 03:55:38 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07964 for ; Tue, 5 Nov 2002 03:52:59 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 5 Nov 2002 09:49:13 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 09:49:13 +0100 Message-Id: From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Tue, 5 Nov 2002 09:49:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA58tdv24472 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi John, I'd like to to keep a reservation ID as a requirement and I prefer to look at it as a "must" (no capitals). Two issues: it may save signaling load if you refresh by using reservation IDs instead of flow IDs. That may be intersting on wireless interfaces, but not only there. The other argument I see is aggregation. I'm aware of RFC 3175 and I regard the aggregation mechanism designed there as smart but non trivial. A reservation ID may be useful in this context. I've twice used "may" here. It would be great if could decide on the strength of requirement (must, should, may) after we checked some real world designs and a proof of concept. Regards, Rüdiger > > Bob Bradeb wrote: > > Actually, only trouble I have with this statement is capitalizing > > MUST. By its very definition, a reservation identifier is > > independent of the flow identifier (otherwise, we wouldn't call > > it a reservation identifier, we would call it a flow identifier, > > right?) Since the independence is by definition, not de jure, > > there is no place for MUST here -- there is no requirement. > > The requirement (should it be agreed > > upon), would simply be that the protocol MUST support a reservation > > identifier. > > > > HINT: The best list of requirements is the shortest list, not the > > longest list. > John Loughney wrote: > I think I agree. It actually also sounds very much like a protocol > specific issue. Is the issue really that we would like to > have seperation between a reservation & a flow? Perhaps this is > one requirement we can drop. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 03:56: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 DAA08032 for ; Tue, 5 Nov 2002 03:56:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA58x6024686 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 03:59: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 gA58x3v24679; Tue, 5 Nov 2002 03:59: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 gA58wVv24659 for ; Tue, 5 Nov 2002 03:58:31 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08026 for ; Tue, 5 Nov 2002 03:55:52 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 5 Nov 2002 09:51:31 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 09:51:31 +0100 Message-Id: From: "Geib, Ruediger" To: robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Tue, 5 Nov 2002 09:51:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA58wVv24660 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Robert, > The hard point is the security aspect, since so far as I can > tell, (in general) any random node in the Internet could pop > up and say "I want to modify reservation XXX 'cos it's really > mine", and it would be hard to decide whether it wasn't just > the real node having moved. All it has to do is get it's > signalling message to intersect the existing path for that > reservation id. Do you want to say that flow Id's provide better security? Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 04:01: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 EAA08089 for ; Tue, 5 Nov 2002 04:01:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5939025160 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 04:03:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5936v25151; Tue, 5 Nov 2002 04:03: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 gA592Cv25109 for ; Tue, 5 Nov 2002 04:02:12 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08059 for ; Tue, 5 Nov 2002 03:59:32 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA591xQ1002897; Tue, 5 Nov 2002 10:01:59 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WJNZ99QP; Tue, 5 Nov 2002 10:01:58 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 10:01:15 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE176@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: e6c0e477 ca231590 e3fd16f2 00000138 From: "Georgios Karagiannis (ELN)" To: "'brunner@ccrle.nec.de'" , nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 1: Local Information Exchange Date: Tue, 5 Nov 2002 10:01:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Marcus I agree with the modifications on the Local Information Exchange sections. Best Regards, Georgios -----Original Message----- From: Marcus Brunner [mailto:brunner@ccrle.nec.de] Sent: vrijdag 1 november 2002 23:32 To: nsis@ietf.org Subject: [NSIS] Req-Draft: Open Issue 1: Local Information Exchange Req-Draft: Open Issue 1: Local Information Exchange ------------------------------------------ We have 2 requirements 5.3.5 and 5.4.2 about this. What is required a) add domain local information to NSIS protocol messages and/or b) allow to use NSIS messges for domain internal communication, e.g., coordination between several NSIS forwarders -05 text of the two reqs 5.3.5 Local information exchange The signaling protocol MUST be able to exchange local information between NSIS Forwarders located within one single administrative domain. Local information might, for example, be IP addresses, severe congestion notification, notification of successful or erroneous processing of signaling messages. In some cases, the NSIS signaling protocol MAY carry identification of the NSIS Forwarders located at the boundaries of a domain. However, the identification of edge should not be visible to the end host (NSIS Initiator) and only applies within one administrative domain. 5.4.2 Possibility to add and remove local domain information It SHOULD be possible for the Resource Management Function to add and remove local scope elements. E.g., at the entrance to a domain domain-specific information is added, which is used in this domain only, and the information is removed again when a signaling message leaves the domain. The motivation is in the economy of re-use the protocol for domain internal signaling of various information pieces. Where additional information is needed within a particular domain, it should be possible to carry this at the same time as the end-to-end information. -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 04:04: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 EAA08137 for ; Tue, 5 Nov 2002 04:04:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA596Cb25356 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 04:06: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 gA5969v25334; Tue, 5 Nov 2002 04:06: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 gA5958v25289 for ; Tue, 5 Nov 2002 04:05:08 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08118 for ; Tue, 5 Nov 2002 04:02:28 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 09:04:54 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA699@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Tue, 5 Nov 2002 09:04:49 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA5958v25290 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit yes, after a fashion. see e.g. http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg01993.html it's not cryptographic security, of course. robert h. > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 05 November 2002 08:51 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of > reservation > i dentifier > > > Robert, > > > The hard point is the security aspect, since so far as I can > > tell, (in general) any random node in the Internet could pop > > up and say "I want to modify reservation XXX 'cos it's really > > mine", and it would be hard to decide whether it wasn't just > > the real node having moved. All it has to do is get it's > > signalling message to intersect the existing path for that > > reservation id. > > Do you want to say that flow Id's provide better security? > > Regards, Rüdiger > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 04:08: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 EAA08200 for ; Tue, 5 Nov 2002 04:08:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA59B7Z26135 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 04:11: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 gA59B4v26116; Tue, 5 Nov 2002 04:11: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 gA5972v25428 for ; Tue, 5 Nov 2002 04:07:02 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08152 for ; Tue, 5 Nov 2002 04:04:23 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 5 Nov 2002 09:58:30 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 09:58:29 +0100 Message-Id: From: "Geib, Ruediger" To: Hannes.Tschofenig@siemens.com Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Date: Tue, 5 Nov 2002 09:58:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA5973v25429 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello Hannes, you seem to raise an archcitectural aspect. I agree, Midcom signaling may require encryption. QoS signaling may do well with integrity protection. Would you agree that certain "upper level signaling protocols" may have to be encrypted while others don't have to be? Or is it already the CSTP level which must be encrypted? Regards, Rüdiger > > Rüdiger wrote: > > I agree with Bob that encryption of signaling messages > > is an option, not a requirement. > Hannes wrote > what i would like to prevent is that a requirement for > encryption is so fuzzy that actually nobody applies it > their protocol proposals. adding confidentiality > protection later to a protocol is often quite > difficult. > protocol designers should consider it during the initial > design. an area where is see a need for confidentiality > protection is communication of policy rules (midcom). > providing protection against traffic analysis is also > a good goal to achieve looking at the increasing importance > of privacy issues. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 05:05: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 FAA09061 for ; Tue, 5 Nov 2002 05:05:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5A7QQ29717 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 05:07: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 gA5A7Ov29706; Tue, 5 Nov 2002 05:07: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 gA5A6nv29106 for ; Tue, 5 Nov 2002 05:06:49 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09044 for ; Tue, 5 Nov 2002 05:04:20 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA5A6mKV025653 for ; Tue, 5 Nov 2002 11:06:48 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WJRFLKM4; Tue, 5 Nov 2002 11:06:48 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 11:06:04 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE178@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 10d21820 ca231590 e3fd16f2 00000138 From: "Georgios Karagiannis (ELN)" To: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Date: Tue, 5 Nov 2002 11:06:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Hannes sorry, but I think that I agree with Bob on this! Best Regards, Georgios -----Original Message----- From: Bob Braden [mailto:braden@ISI.EDU] Sent: maandag 4 november 2002 18:26 To: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages *> *> hi marcus *> *> i would agree to a stronger requirement for confidentiality protection of *> signaling messages. *> *> how about: *> *> "NSIS signaling messages MUST be confidentiality protected between NSIS *> nodes." *> *> ciao *> hannes *> *> Whoa!!! Strong encryption has a cost, and it is by no means clear that very many users of your protocol are going to want or need to pay that cost in order to protect confidentiality of signaling. Your version shifts from a requirement for support, which was reasonable, to a requirement for implementation and use, which is out of bounds. Bob Braden *> > -----Original Message----- *> > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of *> > Marcus Brunner *> > Sent: Friday, November 01, 2002 11:35 PM *> > To: nsis@ietf.org *> > Subject: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling *> > messages *> > *> > *> > *> > Req-Draft: Open Issue 4: Confidentiality of signaling messages *> > --------------------------------------------------- *> > *> > Proposal to change Req 5.7.8 *> > "The NSIS protocol MUST allow encryption of NSIS messages between NSIS *> > nodes." *> > *> > Currently it says *> > *> > 5.7.8 Confidentiality of signaling messages *> > *> > Based on the signaling information exchanged between nodes *> > participating in *> > the signaling protocol an adversary may learn both the identities and the *> > content of the signaling messages. To prevent this from happening, *> > confidentiality of the signaling message in a hop-by-hop manner MAY be *> > provided. Note that the protection can be provided on a hop-by-hop basis *> > for most message payloads since it is required that entities *> > which actively *> > participating in the signaling protocol must be able to read and *> > eventually *> > modify the content of the signaling messages." *> > *> > -------------------------------------- *> > Dr. Marcus Brunner *> > Network Laboratories *> > NEC Europe Ltd. *> > *> > E-Mail: brunner@ccrle.nec.de *> > WWW: http://www.ccrle.nec.de/ *> > Phone: +49 (0) 6221 905 11 29 *> > personal home page: http://www.brubers.org/marcus *> > *> > *> > _______________________________________________ *> > nsis mailing list *> > nsis@ietf.org *> > https://www1.ietf.org/mailman/listinfo/nsis *> *> _______________________________________________ *> nsis mailing list *> nsis@ietf.org *> https://www1.ietf.org/mailman/listinfo/nsis *> ----- End Included Message ----- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 05:43: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 FAA09552 for ; Tue, 5 Nov 2002 05:43:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5AjBg31987 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 05:45: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 gA5Aj8v31979; Tue, 5 Nov 2002 05:45: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 gA5AiAv31939 for ; Tue, 5 Nov 2002 05:44:10 -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 FAA09547 for ; Tue, 5 Nov 2002 05:41:40 -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 gA5Ai8Y51156; Tue, 5 Nov 2002 11:44:08 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id F17C0711B8; Tue, 5 Nov 2002 11:43:37 +0100 (CET) Date: Tue, 05 Nov 2002 11:43:39 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Hancock, Robert" Cc: nsis@ietf.org Subject: link to req-05 (was RE: [NSIS] updated req draft -05 submitted) Message-ID: <6931236.1036496618@[192.168.102.207]> In-Reply-To: <76C92FBBFB58D411AE760090271ED41805DF5D24@rsys002a.roke.co.uk> References: <76C92FBBFB58D411AE760090271ED41805DF5D24@rsys002a.roke.co.uk> X-Mailer: Mulberry/2.2.0 (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: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit http://www.brubers.org/marcus/papers/draft-ietf-nsis-req-05.txt Marcus --On Montag, 4. November 2002 19:20 +0000 "Hancock, Robert" wrote: > marcus, > > can you post a link? it'll be hard to discuss the details otherwise over > the next few days. > > (i can put it up somewhere if it's hard for you.) > > cheers, > > robert > >> -----Original Message----- >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> Sent: 01 November 2002 22:04 >> To: nsis@ietf.org >> Subject: [NSIS] updated req draft -05 submitted >> >> >> I have submitted the next revision of the reqirements draft. >> >> Here is the change log >> Changes 04 -> 05 >> >> 1) removed QoS specifics as far as possible, still used as >> examples at >> several places. >> >> 2) Removed text from Section 1-3. >> >> 3) Changes exclusion 11 on "Handoff decision and trigger >> sources" into: >> >> 11. Handoff decision and trigger sources: An NSIS protocol >> is not used >> to trigger handoffs in mobile IP, nor is it used to decide whether to >> handoff or not. As soon as or in some situation even before a handoff >> happened, an NSIS protocol might be used for signaling for >> QoS again. The >> basic underlying assumption is that the route comes first >> (defining the >> path) and the signaling comes after it (following the path). >> This doesn't >> prevent a signaling application at some node interacting with >> something >> that modifies the path, but the requirement is then just for >> NSIS to live >> with that possibility. However, NSIS must interwork with >> several protocols >> for mobility management. >> >> 4) change in section 5 >> From: >> "All of them are not strictly defined and should not be >> regarded as that, >> but should give a feeling about where in the network we have >> different >> requirements concerning signaling." >> >> To: >> "These divisions between network types are not strict and do >> not appear in >> all networks, but where they do exist they may influence signaling >> requirements and will be highlighted as necessary." >> >> 5) change req 5.2.3 >> >> SHOULD in 2nd paragraph changed to lower-case >> >> 6) changed title of 5.3 into "Messaging" >> >> 7) req 5.3.3 changed >> From: >> SHOULD be able to notify >> >> To: >> SHOULD notify >> >> 8) change req 5.3.4 >> >> Second MAY is now lowercase >> >> 9) req 5.6.3 >> changed sender -> NSIS Initiator, >> receiver into NSIS Responder >> >> 10) created separate req section with the NF initiation req. >> Keeps the same >> text >> >> 11) removed last sentence of req 5.7.4 >> >> 12) changed req 5.9.2 >> >> From: >> >> "The solution MUST NOT constrain either to IPv4 or IPv6" >> >> To: >> >> "The NSIS protocol MUST support IPv4 and IPv6." >> >> 13) change req 5.9.4 "SHOULD provide hooks for AAA protocols" >> >> From: >> >> The security mechanism SHOULD be developed with respect to be able to >> collect usage records from one or more network elements. >> >> To: >> >> The NSIS SHOULD be developed with respect to be able to collect usage >> records from one or more network elements. >> >> 14) remove text from req 5.9.5 >> >> New it says: "An NSIS protocol SHOULD interwork with seamless handoff >> protocols such as context transfer and candidate access router (CAR) >> discovery." >> >> 15) Change requirement 5.10.3 >> >> From: >> "NSIS peers SHOULD be able to detect the malfunctioning peer. >> It may notify >> the NSIS Initiator or another NSIS entity involved in the signaling >> process. The NSIS peer may handle the problem itself e.g. >> switching to a >> backup NSIS entity. In the latter case note that >> synchronization of state >> between the primary and the backup entity is needed." >> >> To: >> >> "NSIS peers SHOULD be able to detect the malfunctioning peer. >> It SHOULD >> notify the NSIS Initiator or another NSIS entity involved in >> the signaling >> process. The NSIS peer may handle the problem itself e.g. >> switching to a >> backup NSIS entity. " >> >> 16) Section 6: changed "threads" should be "threats" >> >> -------------------------------------- >> Dr. Marcus Brunner >> Network Laboratories >> NEC Europe Ltd. >> >> E-Mail: brunner@ccrle.nec.de >> WWW: http://www.ccrle.nec.de/ >> Phone: +49 (0) 6221 905 11 29 >> personal home page: http://www.brubers.org/marcus >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 06:01: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 GAA09733 for ; Tue, 5 Nov 2002 06:01:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5B3Cl32479 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 06:03: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 gA5B39v32470; Tue, 5 Nov 2002 06: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 gA5B2Hv32446 for ; Tue, 5 Nov 2002 06:02: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 FAA09683 for ; Tue, 5 Nov 2002 05:59: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 gA5B2FY52534; Tue, 5 Nov 2002 12:02:15 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 8559060A62; Tue, 5 Nov 2002 12:01:45 +0100 (CET) Date: Tue, 05 Nov 2002 12:01:46 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Bob Braden , nsis@ietf.org Subject: Re: [NSIS] Comments on requirements draft Message-ID: <8018810.1036497706@[192.168.102.207]> In-Reply-To: <200211041641.QAA03929@gra.isi.edu> References: <200211041641.QAA03929@gra.isi.edu> X-Mailer: Mulberry/2.2.0 (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: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks for clarification. In the req draft we currently have a reference to the Security Threats "NSIS Threats" draft. MArcus --On Montag, 4. November 2002 16:41 +0000 Bob Braden wrote: > *> > *> >References need to be split into normative and informative > *> > *> there are no non-normative references > > Marcus, > > Actually, this normative business is a little confusing for everybody. > From the viewpoint of the RFC Editor, the normative attribute is really > relevant only on standards track documents (or BCPs, which are > quasi-standards). Since this is a requirements draft that will not be > a standard of any kind, some believe that NONE of its references need > be normative. > > The practical consequence of a normative reference is that it may hold > up publication if the referenced document has not itself been > published. Mutual normative references force a group of RFCs to be > published simultaneously, often holding them all up because due to a > minor glitch in one of them. If the referenced documet is already > published, making a normative reference to it has no practical > consequences. > > Bob Braden -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 06:13: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 GAA11568 for ; Tue, 5 Nov 2002 06:13:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5BFJX01248 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 06:15:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5BFHv01241; Tue, 5 Nov 2002 06:15: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 gA5B9hv00826 for ; Tue, 5 Nov 2002 06:09:43 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10481 for ; Tue, 5 Nov 2002 06:07:13 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA5B9fQ1021560; Tue, 5 Nov 2002 12:09:41 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WJS4ALYJ; Tue, 5 Nov 2002 12:09:41 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 12:02:51 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE179@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 2274b790 ca231590 e3fd16f2 00000138 From: "Georgios Karagiannis (ELN)" To: "'Hancock, Robert'" Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Tue, 5 Nov 2002 12:09:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Robert There might be other situations than supporting mobility scenarios, where you might need independence of the reservation identifier. For example, think about SCTP which supports multiple source and destination addresses, i.e., the SCTP Multi-Homing Feature (see ftp://ftp.rfc-editor.org/in-notes/rfc3286.txt) Best Regards, Georgios -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: maandag 4 november 2002 20:21 To: Bob Braden; nsis@ietf.org; brunner@ccrle.nec.de Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier hi all, I confess being somewhat in a dilemma about this one. Please excuse the following somewhat discursive email. On the one hand, I think there is (fairly) widespread consensus that an independent reservation identifier is needed to support certain seamless mobility functions. For example, Mike Thomas' draft includes in 1.2.5: "... this draft makes the wild and perhaps unfounded assumption that the ISSLL working group will step up to allowing RSVP to use a session identifier in addition to the normal 5-tuple to identify a reservation. Given the round trip implications, the author cannot see how seamless mobility with RSVP reservations can be achieved if this assumption is false." What is unclear is (a) whether the improvements over plain resignalling from scratch is worth it (b) especially given that supporting such an identifier is hard. But in any case, if the role of this identifier is supporting mobility scenarios, then we already have a requirement for that (5.8.1, "Allow efficient XXX re-establishment after handover"). If a separate identifier is the only way to meet that, we'll get it anyway. Incidentally, if we delete 'efficient' in 5.8.1 the requirement becomes unambiguous and entirely vacuous, since you can always resignal from scratch. In that sense, we don't need 5.4.3.... On the other hand, we have (I think) a general goal to develop something that can be used for applications and in scenarios we haven't thought of yet, which leads to certain goals about modularity, clean interfaces with other protocols/functions, and so on. Being able to refer to a reservation independently of the flow identification could come into that category of Good Things (like, for example, structuring things as two layers/levels...). But does that mean we need it in the requirements document? It depends what you want to use the requirements document for (which actually isn't clear to me at the moment). My instinctual preference would be to keep it as a should. Cheers, Robert H. > -----Original Message----- > From: Bob Braden [mailto:braden@ISI.EDU] > Sent: 04 November 2002 17:54 > To: nsis@ietf.org; brunner@ccrle.nec.de > Subject: Re: [NSIS] Req-Draft: Open Issue 2: Independence of > reservation > identifier > > > > *> > *> > *> Req-Draft: Open Issue 2: Independence of reservation identifier > *> ---------------------------------------------------- > *> > *> - see thread on NSIS and mobility > *> - is the req needed? > *> - is it needed for a general NSIS base protocol? Or is > it application > *> dependent? > *> > *> 5.4.3 Independence of reservation identifier > *> > *> A reservation identifier MUST be independent of the flow > identifier (flow > > Actually, only trouble I have with this statement is capitalizing > MUST. By its very definition, a reservation identifier is independent > of the flow identifier (otherwise, we wouldn't call it a reservation > identifier, we would call it a flow identifier, right?) Since the > independence is by definition, not de jure, there is no place for MUST > here -- there is no requirement. The requirement (should it be agreed > upon), woudd simply be that the protocol MUST support a reservation > identifier. > > HINT: The best list of requirements is the shortest list, not the > longest list. > > Bob Braden > > *> end-points). Various scenarios in the mobility area require this > *> independence because flows resulting from handoff might > have changed > *> end-points etc. but still have the same service > requirement. Also several > *> proxy-based signaling methods profit from such as independence. > *> > *> > *> -------------------------------------- > *> Dr. Marcus Brunner > *> Network Laboratories > *> NEC Europe Ltd. > *> > *> E-Mail: brunner@ccrle.nec.de > *> WWW: http://www.ccrle.nec.de/ > *> Phone: +49 (0) 6221 905 11 29 > *> personal home page: http://www.brubers.org/marcus > *> > *> > *> _______________________________________________ > *> nsis mailing list > *> nsis@ietf.org > *> https://www1.ietf.org/mailman/listinfo/nsis > *> > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 06:14: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 GAA11696 for ; Tue, 5 Nov 2002 06:14:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5BGOT01404 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 06:16: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 gA5BGMv01367; Tue, 5 Nov 2002 06:16: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 gA5BAPv00862 for ; Tue, 5 Nov 2002 06:10:25 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10621 for ; Tue, 5 Nov 2002 06:07:54 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gA5BAML16864; Tue, 5 Nov 2002 12:10:22 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gA5BAMI29748; Tue, 5 Nov 2002 12:10:22 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Geib, Ruediger" Cc: Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Date: Tue, 5 Nov 2002 12:10:43 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi ruediger! > > Hello Hannes, > > you seem to raise an archcitectural aspect. I agree, > Midcom signaling may require encryption. QoS > signaling may do well with integrity protection. > Would you agree that certain "upper level signaling > protocols" may have to be encrypted while others > don't have to be? no. i would generally like to see encryption because it adds security. the policy rules for midcom was only one example. to prevent traffic analysis and eavesdropping confidentiality protection might also be useful for qos signaling. in the future other application protocols might be added. they also might require encryption. if confidentiality protection is considered during the protocol design phase then it is later only the signaling message initiators choice to select it. it is true that in some environments (for example dial-up links) it might not be required. if confidentiality protection is not considered at all then i argue that it is hard to add. > Or is it already the CSTP level > which must be encrypted? it always depends what information you deliver at each each level/layer. the seperation between these layers is only at a document level/logical and not physical!? providing different security mechanisms at different layers is more difficult. ciao hannes > > Regards, Rüdiger > > > > Rüdiger wrote: > > > I agree with Bob that encryption of signaling messages > > > is an option, not a requirement. > > > Hannes wrote > > what i would like to prevent is that a requirement for > > encryption is so fuzzy that actually nobody applies it > > their protocol proposals. adding confidentiality > > protection later to a protocol is often quite > > difficult. > > protocol designers should consider it during the initial > > design. an area where is see a need for confidentiality > > protection is communication of policy rules (midcom). > > providing protection against traffic analysis is also > > a good goal to achieve looking at the increasing importance > > of privacy issues. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 06:14: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 GAA11720 for ; Tue, 5 Nov 2002 06:14:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5BGPN01423 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 06:16: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 gA5BGNv01390; Tue, 5 Nov 2002 06:16:23 -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 gA5BAQv00866 for ; Tue, 5 Nov 2002 06:10:26 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10622 for ; Tue, 5 Nov 2002 06:07:55 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gA5BANL16870; Tue, 5 Nov 2002 12:10:23 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gA5BANI29759; Tue, 5 Nov 2002 12:10:23 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Georgios Karagiannis \(ELN\)" , Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Date: Tue, 5 Nov 2002 12:10:44 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <2B06CD3FC17AF64587BC7A7617B230C01AE178@enleent103.nl.eu.ericsson.se> Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi georgios i know your point of view. key management is also unfortunately associated with cost. do we skip it only because it is difficult or expensive? maybe we can agree on something like: - in some enviroment confidentiality protection might not be required. - "NSIS signaling messages MUST be possible to be confidentiality protected between NSIS nodes." (like john proposed) ciao hannes > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Georgios Karagiannis (ELN) > Sent: Tuesday, November 05, 2002 11:07 AM > To: nsis@ietf.org > Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of > signaling messages > > > Hi > > Hannes sorry, but I think that I agree with Bob on this! > > Best Regards, > Georgios > > -----Original Message----- > From: Bob Braden [mailto:braden@ISI.EDU] > Sent: maandag 4 november 2002 18:26 > To: nsis@ietf.org > Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of > signaling messages > > > > *> > *> hi marcus > *> > *> i would agree to a stronger requirement for confidentiality > protection of > *> signaling messages. > *> > *> how about: > *> > *> "NSIS signaling messages MUST be confidentiality protected > between NSIS > *> nodes." > *> > *> ciao > *> hannes > *> > *> > > Whoa!!! Strong encryption has a cost, and it is by no means clear that > very many users of your protocol are going to want or need to pay that > cost in order to protect confidentiality of signaling. Your version > shifts from a requirement for support, which was reasonable, to > a requirement for implementation and use, which is out of bounds. > > Bob Braden > > > *> > -----Original Message----- > *> > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > *> > Marcus Brunner > *> > Sent: Friday, November 01, 2002 11:35 PM > *> > To: nsis@ietf.org > *> > Subject: [NSIS] Req-Draft: Open Issue 4: Confidentiality > of signaling > *> > messages > *> > > *> > > *> > > *> > Req-Draft: Open Issue 4: Confidentiality of signaling messages > *> > --------------------------------------------------- > *> > > *> > Proposal to change Req 5.7.8 > *> > "The NSIS protocol MUST allow encryption of NSIS messages > between NSIS > *> > nodes." > *> > > *> > Currently it says > *> > > *> > 5.7.8 Confidentiality of signaling messages > *> > > *> > Based on the signaling information exchanged between nodes > *> > participating in > *> > the signaling protocol an adversary may learn both the > identities and the > *> > content of the signaling messages. To prevent this from happening, > *> > confidentiality of the signaling message in a hop-by-hop > manner MAY be > *> > provided. Note that the protection can be provided on a > hop-by-hop basis > *> > for most message payloads since it is required that entities > *> > which actively > *> > participating in the signaling protocol must be able to read and > *> > eventually > *> > modify the content of the signaling messages." > *> > > *> > -------------------------------------- > *> > Dr. Marcus Brunner > *> > Network Laboratories > *> > NEC Europe Ltd. > *> > > *> > E-Mail: brunner@ccrle.nec.de > *> > WWW: http://www.ccrle.nec.de/ > *> > Phone: +49 (0) 6221 905 11 29 > *> > personal home page: http://www.brubers.org/marcus > *> > > *> > > *> > _______________________________________________ > *> > nsis mailing list > *> > nsis@ietf.org > *> > https://www1.ietf.org/mailman/listinfo/nsis > *> > *> _______________________________________________ > *> nsis mailing list > *> nsis@ietf.org > *> https://www1.ietf.org/mailman/listinfo/nsis > *> > > > ----- End Included Message ----- > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 06:30: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 GAA12787 for ; Tue, 5 Nov 2002 06:30:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5BW9H02773 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 06:32:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5BW7v02736; Tue, 5 Nov 2002 06: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 gA5B7Vv00731 for ; Tue, 5 Nov 2002 06:07:31 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10058; Tue, 5 Nov 2002 06:05:00 -0500 (EST) Message-Id: <200211051105.GAA10058@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 05 Nov 2002 06:05:00 -0500 Subject: [NSIS] I-D ACTION:draft-demeer-nsis-analysis-03.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of Existing QoS Solutions Author(s) : H. De Meer et al. Filename : draft-demeer-nsis-analysis-03.txt Pages : 29 Date : 2002-11-4 This memo provides a brief analysis of existing IP quality of service (QoS) solutions and the implied signalling issues. This analysis is intended to point out open issues in QoS signalling. Moreover, this analysis is done in order to understand whether the strict QoS requirements imposed by future fixed and mobile applications are satisfied by the existing IP QoS solutions. The existing IP QoS solutions can be categorized as follows: * End-to-end per-flow resource reservation protocols * Integrated Services over Differentiated Services * Statically assigned trunk reservations based on Differentiated Services * Dynamic trunk reservations with Aggregated RSVP A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-demeer-nsis-analysis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-demeer-nsis-analysis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-4171312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-demeer-nsis-analysis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-demeer-nsis-analysis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-4171312.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 07: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 HAA14168 for ; Tue, 5 Nov 2002 07:01:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5C3Eq05164 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 07:03: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 gA5C3Cv05157; Tue, 5 Nov 2002 07:03: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 gA5C2Wv05126 for ; Tue, 5 Nov 2002 07:02:32 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14116 for ; Tue, 5 Nov 2002 07:00:03 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 12:02:29 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA69B@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Georgios Karagiannis (ELN)'" Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Tue, 5 Nov 2002 12:02:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi Georgios, Nice example (also comes up in the v6 flow label draft). Rudi has mentioned reservation bundling/aggregation. I am sure there are others (as well as mobility of course). So that would come into my second category of motivation (see "on the other hand" below): we see several examples of how it can be useful to refer to a reservation independently of the specific flow it is associated with; therefore, it should (SHOULD? MUST? may) be a basic protocol capability (in that it will support applications we haven't even thought of yet). On the *other* other hand, how much is there a danger of this being a clever feature whose main role is as a source of arguments unless its use is really carefully defined at the outset? (For comparison, I'll just mention 'site local addresses'...) Cheers, Robert H. > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 05 November 2002 11:10 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of > reservation > i dentifier > > > Hi Robert > > There might be other situations than supporting mobility scenarios, > where you might need independence of the reservation identifier. > For example, think about SCTP which supports multiple source and > destination addresses, i.e., the SCTP Multi-Homing Feature (see > ftp://ftp.rfc-editor.org/in-notes/rfc3286.txt) > > Best Regards, > Georgios > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: maandag 4 november 2002 20:21 > To: Bob Braden; nsis@ietf.org; brunner@ccrle.nec.de > Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of > reservation > i dentifier > > > hi all, > > I confess being somewhat in a dilemma about this one. Please > excuse the following somewhat discursive email. > > On the one hand, I think there is (fairly) widespread > consensus that an independent reservation identifier is > needed to support certain seamless mobility functions. For > example, Mike Thomas' draft includes in 1.2.5: > > "... this draft makes the wild and perhaps unfounded > assumption that the ISSLL working group will step up to > allowing RSVP > to use a session identifier in addition to the normal 5-tuple to > identify a reservation. Given the round trip implications, > the author > cannot see how seamless mobility with RSVP reservations can be > achieved if this assumption is false." > > What is unclear is > (a) whether the improvements over plain resignalling from > scratch is worth it > (b) especially given that supporting such an identifier is hard. > > But in any case, if the role of this identifier is supporting > mobility scenarios, then we already have a requirement for > that (5.8.1, "Allow efficient XXX re-establishment after > handover"). If a separate identifier is the only way to meet > that, we'll get it anyway. Incidentally, if we delete > 'efficient' in 5.8.1 the requirement becomes unambiguous and > entirely vacuous, since you can always resignal from scratch. > > In that sense, we don't need 5.4.3.... > > On the other hand, we have (I think) a general goal to > develop something that can be used for applications and in > scenarios we haven't thought of yet, which leads to certain > goals about modularity, clean interfaces with other > protocols/functions, and so on. Being able to refer to a > reservation independently of the flow identification could > come into that category of Good Things (like, for example, > structuring things as two layers/levels...). But does that > mean we need it in the requirements document? It depends what > you want to use the requirements document for (which actually > isn't clear to me at the moment). > > My instinctual preference would be to keep it as a should. > > Cheers, > > Robert H. > > > -----Original Message----- > > From: Bob Braden [mailto:braden@ISI.EDU] > > Sent: 04 November 2002 17:54 > > To: nsis@ietf.org; brunner@ccrle.nec.de > > Subject: Re: [NSIS] Req-Draft: Open Issue 2: Independence of > > reservation > > identifier > > > > > > > > *> > > *> > > *> Req-Draft: Open Issue 2: Independence of reservation identifier > > *> ---------------------------------------------------- > > *> > > *> - see thread on NSIS and mobility > > *> - is the req needed? > > *> - is it needed for a general NSIS base protocol? Or is > > it application > > *> dependent? > > *> > > *> 5.4.3 Independence of reservation identifier > > *> > > *> A reservation identifier MUST be independent of the flow > > identifier (flow > > > > Actually, only trouble I have with this statement is capitalizing > > MUST. By its very definition, a reservation identifier is > independent > > of the flow identifier (otherwise, we wouldn't call it a reservation > > identifier, we would call it a flow identifier, right?) Since the > > independence is by definition, not de jure, there is no > place for MUST > > here -- there is no requirement. The requirement (should > it be agreed > > upon), woudd simply be that the protocol MUST support a reservation > > identifier. > > > > HINT: The best list of requirements is the shortest list, not the > > longest list. > > > > Bob Braden > > > > *> end-points). Various scenarios in the mobility area > require this > > *> independence because flows resulting from handoff might > > have changed > > *> end-points etc. but still have the same service > > requirement. Also several > > *> proxy-based signaling methods profit from such as independence. > > *> > > *> > > *> -------------------------------------- > > *> Dr. Marcus Brunner > > *> Network Laboratories > > *> NEC Europe Ltd. > > *> > > *> E-Mail: brunner@ccrle.nec.de > > *> WWW: http://www.ccrle.nec.de/ > > *> Phone: +49 (0) 6221 905 11 29 > > *> personal home page: http://www.brubers.org/marcus > > *> > > *> > > *> _______________________________________________ > > *> nsis mailing list > > *> nsis@ietf.org > > *> https://www1.ietf.org/mailman/listinfo/nsis > > *> > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 07:39: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 HAA15660 for ; Tue, 5 Nov 2002 07:39:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5CfHw07959 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 07:41: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 gA5CfDv07951; Tue, 5 Nov 2002 07: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 gA5Ce5v07915 for ; Tue, 5 Nov 2002 07:40:05 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15594 for ; Tue, 5 Nov 2002 07:37:35 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA5Ce2KW022812; Tue, 5 Nov 2002 13:40:02 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WJZW0BX4; Tue, 5 Nov 2002 13:39:59 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 13:33:09 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE17B@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 446d6e68 ca231590 e3fd16f2 00000138 From: "Georgios Karagiannis (ELN)" To: "'Hannes.Tschofenig@siemens.com'" , nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Date: Tue, 5 Nov 2002 13:39:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Hannes Combining the two bullets might be acceptable to me! Best Regards, Georgios -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@siemens.com] Sent: dinsdag 5 november 2002 12:11 To: Georgios Karagiannis (ELN); nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages hi georgios i know your point of view. key management is also unfortunately associated with cost. do we skip it only because it is difficult or expensive? maybe we can agree on something like: - in some enviroment confidentiality protection might not be required. - "NSIS signaling messages MUST be possible to be confidentiality protected between NSIS nodes." (like john proposed) ciao hannes > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Georgios Karagiannis (ELN) > Sent: Tuesday, November 05, 2002 11:07 AM > To: nsis@ietf.org > Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of > signaling messages > > > Hi > > Hannes sorry, but I think that I agree with Bob on this! > > Best Regards, > Georgios > > -----Original Message----- > From: Bob Braden [mailto:braden@ISI.EDU] > Sent: maandag 4 november 2002 18:26 > To: nsis@ietf.org > Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of > signaling messages > > > > *> > *> hi marcus > *> > *> i would agree to a stronger requirement for confidentiality > protection of > *> signaling messages. > *> > *> how about: > *> > *> "NSIS signaling messages MUST be confidentiality protected > between NSIS > *> nodes." > *> > *> ciao > *> hannes > *> > *> > > Whoa!!! Strong encryption has a cost, and it is by no means clear that > very many users of your protocol are going to want or need to pay that > cost in order to protect confidentiality of signaling. Your version > shifts from a requirement for support, which was reasonable, to > a requirement for implementation and use, which is out of bounds. > > Bob Braden > > > *> > -----Original Message----- > *> > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > *> > Marcus Brunner > *> > Sent: Friday, November 01, 2002 11:35 PM > *> > To: nsis@ietf.org > *> > Subject: [NSIS] Req-Draft: Open Issue 4: Confidentiality > of signaling > *> > messages > *> > > *> > > *> > > *> > Req-Draft: Open Issue 4: Confidentiality of signaling messages > *> > --------------------------------------------------- > *> > > *> > Proposal to change Req 5.7.8 > *> > "The NSIS protocol MUST allow encryption of NSIS messages > between NSIS > *> > nodes." > *> > > *> > Currently it says > *> > > *> > 5.7.8 Confidentiality of signaling messages > *> > > *> > Based on the signaling information exchanged between nodes > *> > participating in > *> > the signaling protocol an adversary may learn both the > identities and the > *> > content of the signaling messages. To prevent this from happening, > *> > confidentiality of the signaling message in a hop-by-hop > manner MAY be > *> > provided. Note that the protection can be provided on a > hop-by-hop basis > *> > for most message payloads since it is required that entities > *> > which actively > *> > participating in the signaling protocol must be able to read and > *> > eventually > *> > modify the content of the signaling messages." > *> > > *> > -------------------------------------- > *> > Dr. Marcus Brunner > *> > Network Laboratories > *> > NEC Europe Ltd. > *> > > *> > E-Mail: brunner@ccrle.nec.de > *> > WWW: http://www.ccrle.nec.de/ > *> > Phone: +49 (0) 6221 905 11 29 > *> > personal home page: http://www.brubers.org/marcus > *> > > *> > > *> > _______________________________________________ > *> > nsis mailing list > *> > nsis@ietf.org > *> > https://www1.ietf.org/mailman/listinfo/nsis > *> > *> _______________________________________________ > *> nsis mailing list > *> nsis@ietf.org > *> https://www1.ietf.org/mailman/listinfo/nsis > *> > > > ----- End Included Message ----- > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 08:17: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 IAA17093 for ; Tue, 5 Nov 2002 08:17:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5DJIK09708 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 08:19: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 gA5DJGv09701; Tue, 5 Nov 2002 08:19: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 gA5DIWv09675 for ; Tue, 5 Nov 2002 08:18:32 -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 IAA17064 for ; Tue, 5 Nov 2002 08:16:02 -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 gA5DIBY59660; Tue, 5 Nov 2002 14:18:11 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 2C1C77435E; Tue, 5 Nov 2002 14:17:41 +0100 (CET) Date: Tue, 05 Nov 2002 14:17:41 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: john.loughney@nokia.com, mshore@cisco.com, nsis@ietf.org Subject: RE: [NSIS] Comments on requirements draft Message-ID: <16175258.1036505861@[192.168.102.207]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On Montag, 4. November 2002 10:55 +0200 john.loughney@nokia.com wrote: > Hi Marcus, > >> > should be "NSIS Working Group", not "Network Working Group" >> >> need to check > > It should be NSIS Working Group. > Then show me one RFC where the IETF working group is mentioned. Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 08:32: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 IAA17738 for ; Tue, 5 Nov 2002 08:32:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5DYCV10306 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 08:34: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 gA5DY9v10298; Tue, 5 Nov 2002 08:34: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 gA5DXiv10281 for ; Tue, 5 Nov 2002 08:33:44 -0500 Received: from fw1a.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17704 for ; Tue, 5 Nov 2002 08:31:15 -0500 (EST) Received: by fw1a.telekom.de; (8.8.8/1.3/10May95) id OAA21403; Tue, 5 Nov 2002 14:30:03 +0100 (MET) Received: from g8pbr.blf01.telekom.de by G8PXB.blf01.telekom.de with ESMTP; Tue, 5 Nov 2002 14:23:34 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 14:23:31 +0100 Message-Id: From: "Geib, Ruediger" To: robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Tue, 5 Nov 2002 14:23:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA5DXiv10282 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit The thread you refer to is about mobility and addresses. What's the relation to a reservation ID? Regards, Rüdiger > yes, after a fashion. > > see e.g. > http://www1.ietf.org/mail-archive/working-groups/nsis/current/ msg01993.html it's not cryptographic security, of course. robert h. > Robert, > > > The hard point is the security aspect, since so far as I can > > tell, (in general) any random node in the Internet could pop > > up and say "I want to modify reservation XXX 'cos it's really > > mine", and it would be hard to decide whether it wasn't just > > the real node having moved. All it has to do is get it's > > signalling message to intersect the existing path for that > > reservation id. > > Do you want to say that flow Id's provide better security? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 08:37: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 IAA17890 for ; Tue, 5 Nov 2002 08:37:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5Dd5u11088 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 08:39:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5Dd3v11081; Tue, 5 Nov 2002 08:39: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 gA5Dcnv11059 for ; Tue, 5 Nov 2002 08:38:49 -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 IAA17873 for ; Tue, 5 Nov 2002 08:36:19 -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 gA5DckY61466; Tue, 5 Nov 2002 14:38:46 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C37B461D16; Tue, 5 Nov 2002 14:38:15 +0100 (CET) Date: Tue, 05 Nov 2002 14:38:16 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Bob Braden , nsis@ietf.org Subject: Re: [NSIS] Req-Draft: Open Issue 2: Independence of reservation identifier Message-ID: <17410865.1036507096@[192.168.102.207]> In-Reply-To: <200211041753.RAA04098@gra.isi.edu> References: <200211041753.RAA04098@gra.isi.edu> X-Mailer: Mulberry/2.2.0 (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: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bob, Just for clarification. Is the emphesis on the independence the problem? Or is the reservation ID itself the problem? So reformulating the requirement into "An NSIS protocol MUST support a reservation identifer" would solve the first one. The reservation identifier then can be the same as the flow id or can be something else. Marcus or are you > Actually, only trouble I have with this statement is capitalizing > MUST. By its very definition, a reservation identifier is independent > of the flow identifier (otherwise, we wouldn't call it a reservation > identifier, we would call it a flow identifier, right?) Since the > independence is by definition, not de jure, there is no place for MUST > here -- there is no requirement. The requirement (should it be agreed > upon), woudd simply be that the protocol MUST support a reservation > identifier. > > HINT: The best list of requirements is the shortest list, not the > longest list. > > Bob Braden > > *> end-points). Various scenarios in the mobility area require this > *> independence because flows resulting from handoff might have changed > *> end-points etc. but still have the same service requirement. Also > several *> proxy-based signaling methods profit from such as > independence. *> > *> > *> -------------------------------------- > *> Dr. Marcus Brunner > *> Network Laboratories > *> NEC Europe Ltd. > *> > *> E-Mail: brunner@ccrle.nec.de > *> WWW: http://www.ccrle.nec.de/ > *> Phone: +49 (0) 6221 905 11 29 > *> personal home page: http://www.brubers.org/marcus > *> > *> > *> _______________________________________________ > *> nsis mailing list > *> nsis@ietf.org > *> https://www1.ietf.org/mailman/listinfo/nsis > *> -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 08:38: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 IAA17937 for ; Tue, 5 Nov 2002 08:38:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5De5Q11172 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 08:40:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5De3v11157; Tue, 5 Nov 2002 08:40: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 gA5Dddv11108 for ; Tue, 5 Nov 2002 08:39:39 -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 IAA17904 for ; Tue, 5 Nov 2002 08:37:09 -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 gA5DdTgM028116; Tue, 5 Nov 2002 05:39:29 -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 AAR27287; Tue, 5 Nov 2002 05:34:49 -0800 (PST) Message-Id: <200211051334.AAR27287@mira-sjc5-4.cisco.com> To: "Georgios Karagiannis (ELN)" cc: "'Hannes.Tschofenig@siemens.com'" , nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages In-Reply-To: Message from "Georgios Karagiannis (ELN)" of "Tue, 05 Nov 2002 13:39:57 +0100." <2B06CD3FC17AF64587BC7A7617B230C01AE17B@enleent103.nl.eu.ericsson.se> Date: Tue, 05 Nov 2002 08:39:32 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , I'd tweak the English so that it's more idiomatic: "It MUST be possible to confidentiality-protect signaling messages between NSIS Entities." [n.b. I changed it to "NSIS Entities" to match language in the framework document, but there still seems to be some slop around "Entities" and "Nodes" - I can live with either] Melinda [still catching up on old email] _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 08: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 IAA18248 for ; Tue, 5 Nov 2002 08:45:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5DlEh11436 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 08:47: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 gA5DlBv11426; Tue, 5 Nov 2002 08:47: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 gA5Dkuv11399 for ; Tue, 5 Nov 2002 08:46:56 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18184 for ; Tue, 5 Nov 2002 08:44:26 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 13:46:53 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA6A0@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Tue, 5 Nov 2002 13:46:48 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA5Dkuv11400 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, well, the question as i understood it was: isn't using a flow id (=, in framework terminology, some address fields/ports and so on) just as insecure as a reservation identifier? answer: no, because the behaviour of the network ties the flow id (non-cryptographically) to the relevant parties (flow endpoints) - which is what the referred-to message asserts - whereas the reservation id (to be useful) is independent of any such constraint or guarantee. or did i misunderstand the question? cheers, robert h. > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 05 November 2002 13:23 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of > reservation > i dentifier > > > The thread you refer to is about mobility and addresses. > What's the relation to a reservation ID? > > Regards, Rüdiger > > > yes, after a fashion. > > > > see e.g. > > http://www1.ietf.org/mail-archive/working-groups/nsis/current/ > msg01993.html > > it's not cryptographic security, of course. > > robert h. > > > > Robert, > > > > > The hard point is the security aspect, since so far as I can > > > tell, (in general) any random node in the Internet could pop > > > up and say "I want to modify reservation XXX 'cos it's really > > > mine", and it would be hard to decide whether it wasn't just > > > the real node having moved. All it has to do is get it's > > > signalling message to intersect the existing path for that > > > reservation id. > > > > Do you want to say that flow Id's provide better security? > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 08:47: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 IAA18305 for ; Tue, 5 Nov 2002 08:47:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5Dn4J12324 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 08:49: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 gA5Dn2v12317; Tue, 5 Nov 2002 08: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 gA5DmTv12291 for ; Tue, 5 Nov 2002 08:48:29 -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 IAA18295 for ; Tue, 5 Nov 2002 08:45:59 -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 gA5DmBxF029536; Tue, 5 Nov 2002 05:48:11 -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 AAR27402; Tue, 5 Nov 2002 05:43:33 -0800 (PST) Message-Id: <200211051343.AAR27402@mira-sjc5-4.cisco.com> To: brunner@ccrle.nec.de cc: john.loughney@nokia.com, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Comments on requirements draft In-Reply-To: Message from Marcus Brunner of "Tue, 05 Nov 2002 14:17:41 +0100." <16175258.1036505861@[192.168.102.207]> Date: Tue, 05 Nov 2002 08:48:17 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > Then show me one RFC where the IETF working group is mentioned. This was my mistake. It should remain "Network Working Group." Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 08:49: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 IAA18447 for ; Tue, 5 Nov 2002 08:49:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5Dp6112443 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 08:51: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 gA5Dp4v12430; Tue, 5 Nov 2002 08:51:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5Douv12394 for ; Tue, 5 Nov 2002 08:50:56 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18396 for ; Tue, 5 Nov 2002 08:48:27 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 13:50:53 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA6A1@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'brunner@ccrle.nec.de'" , Bob Braden , nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Tue, 5 Nov 2002 13:50:50 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Marcus, > So reformulating the requirement into "An NSIS protocol MUST > support a > reservation identifer" would solve the first one. The reservation > identifier then can be the same as the flow id or can be > something else. with this interpretation, wouldn't the requirement then be entirely vacuous? i suppose it would rule out reservations which didn't refer to _any_ flows. i think you would have to include the force of Bob's second sentence ("By its very definition, a reservation identifier is independent of the flow identifier (otherwise, we wouldn't call it a reservation identifier, we would call it a flow identifier, right?)") somewhere. Maybe your terminology section... cheers, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 09:07: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 JAA19153 for ; Tue, 5 Nov 2002 09:07:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5E9Uv13677 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 09:09: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 gA5E9Sv13662; Tue, 5 Nov 2002 09:09: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 gA5E5lv12897 for ; Tue, 5 Nov 2002 09:05: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 JAA19021 for ; Tue, 5 Nov 2002 09:03:16 -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 gA5E5iY62818; Tue, 5 Nov 2002 15:05:44 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 037E661DB9; Tue, 5 Nov 2002 15:05:13 +0100 (CET) Date: Tue, 05 Nov 2002 15:05:13 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Hannes.Tschofenig@siemens.com, nsis@ietf.org Subject: Re: [NSIS] Open Issues: Peer-to-Peer Protection Message-ID: <19028131.1036508713@[192.168.102.207]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I am not sure what we need to protect end-to-end can you give some example applications for other then peer-to-peer Marcus --On Dienstag, 5. November 2002 09:35 +0100 Hannes Tschofenig wrote: > hi > > i guess that there is no doubt that a signaling protocol like NSIS must at > least offer peer-to-peer protection. it was often mentioned that more than > peer-to-peer protection might also be required. should there be a > requirement which states something similar? > > ciao > hannes > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 09:10: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 JAA19308 for ; Tue, 5 Nov 2002 09:10:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5EC5W13858 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 09:12:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5EC3v13851; Tue, 5 Nov 2002 09:12: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 gA5EBwv13817 for ; Tue, 5 Nov 2002 09:11:58 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19275 for ; Tue, 5 Nov 2002 09:09:28 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA5EBTO02590 for ; Tue, 5 Nov 2002 16:11:29 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Nov 2002 16:11:54 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 16:11:54 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 16:11:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Open Issues: Peer-to-Peer Protection Date: Tue, 5 Nov 2002 16:11:52 +0200 Message-ID: Thread-Topic: [NSIS] Open Issues: Peer-to-Peer Protection Thread-Index: AcKE1P8t4JYMHIHrQUuHnnRgXVJQqAAABCmA To: , , X-OriginalArrivalTime: 05 Nov 2002 14:11:53.0605 (UTC) FILETIME=[4AB4AB50:01C284D5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA5EBwv13818 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, > I am not sure what we need to protect end-to-end can you give > some example applications for other then peer-to-peer Let's simplify. Let's not get into peer-to-peer vs. end-to-end yet. There will be consideration for this when we better detail the NSIS application layer vs. transport layer stuff. I think it would be appropriate to deal with it in the framework, or some yet unmade protocol architecture document (if we need it). John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 09:22: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 JAA19904 for ; Tue, 5 Nov 2002 09:22:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5EOFi14531 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 09:24:15 -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 gA5EOCv14521; Tue, 5 Nov 2002 09:24: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 gA5EM4v14439 for ; Tue, 5 Nov 2002 09:22:04 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19787 for ; Tue, 5 Nov 2002 09:19:33 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 5 Nov 2002 15:19:32 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 15:19:32 +0100 Message-Id: From: "Geib, Ruediger" To: Hannes.Tschofenig@siemens.com Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Date: Tue, 5 Nov 2002 15:19:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA5EM4v14440 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello Hannes > if confidentiality > protection is not considered at all then i argue that it is > hard to add. Agreed. But I'd prefer to look at it as an option. I'm not sure whether encryption of signaling messages must be made mandatory. > > Rüdiger > > Or is it already the CSTP level > > which must be encrypted? > Hannes > it always depends what information you deliver at each each > level/layer. the seperation between these layers is only > at a document level/logical and not physical!? > providing different security mechanisms at different > layers is more difficult. CASP suggests an omnivorous node, which, as far as I understood, may act as a kind of signaling relay (i.e. no upper level signaling protocol present locally). This means, here's a physical separation of both layers. To me, a simple relay doesn't have to operate encryption. Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 10:20: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 KAA23090 for ; Tue, 5 Nov 2002 10:20:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5FMV218697 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 10:22: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 gA5FMTv18692; Tue, 5 Nov 2002 10:22:29 -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 gA5FDmv18242 for ; Tue, 5 Nov 2002 10:13:48 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22540 for ; Tue, 5 Nov 2002 10:11:16 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 5 Nov 2002 16:11:03 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 16:11:02 +0100 Message-Id: From: "Geib, Ruediger" To: robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Tue, 5 Nov 2002 16:11:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA5FDmv18243 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Robert > well, the question as i understood it was: isn't using a flow > id (=, in framework terminology, some address fields/ports > and so on) just as insecure as a reservation identifier? You got my question. > answer: no, because the behaviour of the network ties the > flow id (non-cryptographically) to the relevant parties (flow > endpoints) - which is what the referred-to message asserts - > whereas the reservation id (to be useful) is independent of > any such constraint or guarantee. The reservation ID is visible on signaling application level. I'd expect a signaling node to save state, including the relevant flow information. So the flow context is re-established by means of the reservation ID. Then the signaling node has the same information as with a flow ID, doesn't it? Changing IP addresses obviously require signaling of a new flow ID. I think the signaling load may be reduced by a reservation ID. You trade that for an additional soft state entry in the router (the reservation ID). I didn't explain the above prior to this message. I don't think this is less secure than repeating the flow ID on signaling application level. Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 11:09: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 LAA26534 for ; Tue, 5 Nov 2002 11:09:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5GBJg23391 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 11:11:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5GBDv23383; Tue, 5 Nov 2002 11:11: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 gA5GAhv23338 for ; Tue, 5 Nov 2002 11:10:43 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26483 for ; Tue, 5 Nov 2002 11:08:11 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Nov 2002 16:10:39 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA6A5@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Tue, 5 Nov 2002 16:10:36 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA5GAhv23339 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, OK, we have 2 aspects of the word secure: 1. privacy of signalling information (your emphasis). here, there is basically no difference between the reservation and flow ids. 2. ability to avoid someone stealing the reservation (my emphasis). here, there is a difference, of a 'soft' sort. Is that the basic point? Cheers, Robert H. > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 05 November 2002 15:11 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of > reservation > i dentifier > > > Robert > > > well, the question as i understood it was: isn't using a flow > > id (=, in framework terminology, some address fields/ports > > and so on) just as insecure as a reservation identifier? > > You got my question. > > > answer: no, because the behaviour of the network ties the > > flow id (non-cryptographically) to the relevant parties (flow > > endpoints) - which is what the referred-to message asserts - > > whereas the reservation id (to be useful) is independent of > > any such constraint or guarantee. > > The reservation ID is visible on signaling application level. > I'd expect a signaling node to save state, including the > relevant flow information. So the flow context is > re-established by means of the reservation ID. Then the > signaling node has the same information as with a flow ID, > doesn't it? > > Changing IP addresses obviously require signaling of a > new flow ID. > > I think the signaling load may be reduced by a reservation ID. > You trade that for an additional soft state entry in the router > (the reservation ID). > > I didn't explain the above prior to this message. I don't > think this is less secure than repeating the flow ID on > signaling application level. > > Regards, Rüdiger > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 11:53: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 LAA28868 for ; Tue, 5 Nov 2002 11:53:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5GtQJ26262 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 11:55: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 gA5GtOv26248; Tue, 5 Nov 2002 11:55: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 gA5Gstv26186 for ; Tue, 5 Nov 2002 11:54:55 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28790 for ; Tue, 5 Nov 2002 11:52:22 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA5Gsma00271; Tue, 5 Nov 2002 08:54:48 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id QAA04604; Tue, 5 Nov 2002 16:54:48 GMT Date: Tue, 5 Nov 2002 16:54:48 GMT Message-Id: <200211051654.QAA04604@gra.isi.edu> To: Hannes.Tschofenig@siemens.com, nsis@ietf.org, brunner@ccrle.nec.de Subject: Re: [NSIS] Open Issues: Peer-to-Peer Protection X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> I am not sure what we need to protect end-to-end can you give some example *> applications for other then peer-to-peer *> *> Marcus *> *> --On Dienstag, 5. November 2002 09:35 +0100 Hannes Tschofenig *> wrote: *> *> > hi *> > *> > i guess that there is no doubt that a signaling protocol like NSIS must at *> > least offer peer-to-peer protection. it was often mentioned that more than *> > peer-to-peer protection might also be required. should there be a *> > requirement which states something similar? *> > *> > ciao *> > hannes *> > Marcus, I don't think it is so much a matter of need as it is of ability. Security wonks always feel uncomfortable about the transitive trust model implied by pure hop/hop integrity. They point out that if any link in the chain is penetrated, then the whole path is penetrated. They would like a digital signature from the signaling initiator that can be checked at every node along the path. (Never mind the CPU cost of that... ;-( ) Unfortunately, the nature of signaling is that in general the contents of the signaling -- the SAPU -- changes in some way from hop to hop along the path. So the best you can do is to sign the invariant parts of the SAPU -- e.g., the session designation. There is no other known solution to the general problem of E2E protection of signaling messages. This problem arose big time in the active networks research program, and Sandy Murphy will be first to admit that she didn't solve it. Bob Braden *> > _______________________________________________ *> > nsis mailing list *> > nsis@ietf.org *> > https://www1.ietf.org/mailman/listinfo/nsis *> *> *> *> -------------------------------------- *> Dr. Marcus Brunner *> Network Laboratories *> NEC Europe Ltd. *> *> E-Mail: brunner@ccrle.nec.de *> WWW: http://www.ccrle.nec.de/ *> Phone: +49 (0) 6221 905 11 29 *> personal home page: http://www.brubers.org/marcus *> *> *> _______________________________________________ *> nsis mailing list *> nsis@ietf.org *> https://www1.ietf.org/mailman/listinfo/nsis *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 12:44: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 MAA01446 for ; Tue, 5 Nov 2002 12:44:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5HkJk29879 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 12:46:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5HkGv29872; Tue, 5 Nov 2002 12:46: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 gA5Hjiv29853 for ; Tue, 5 Nov 2002 12:45:44 -0500 Received: from fig.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01320 for ; Tue, 5 Nov 2002 12:43:11 -0500 (EST) Received: from localhost (berson@localhost) by fig.isi.edu (8.11.6/8.11.6) with ESMTP id gA5HjbH20167; Tue, 5 Nov 2002 09:45:37 -0800 X-Authentication-Warning: fig.isi.edu: berson owned process doing -bs Date: Tue, 5 Nov 2002 09:45:37 -0800 (PST) From: Steven Berson To: Bob Braden cc: Hannes.Tschofenig@siemens.com, , Subject: Re: [NSIS] Open Issues: Peer-to-Peer Protection In-Reply-To: <200211051654.QAA04604@gra.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , On Tue, 5 Nov 2002, Bob Braden wrote: > *> > *> I am not sure what we need to protect end-to-end can you give some example > *> applications for other then peer-to-peer > *> > *> Marcus > *> > *> --On Dienstag, 5. November 2002 09:35 +0100 Hannes Tschofenig > *> wrote: > *> > *> > hi > *> > > *> > i guess that there is no doubt that a signaling protocol like NSIS must at > *> > least offer peer-to-peer protection. it was often mentioned that more than > *> > peer-to-peer protection might also be required. should there be a > *> > requirement which states something similar? > *> > > *> > ciao > *> > hannes > *> > > > Marcus, > > I don't think it is so much a matter of need as it is of ability. > Security wonks always feel uncomfortable about the transitive trust > model implied by pure hop/hop integrity. They point out that if any > link in the chain is penetrated, then the whole path is penetrated. > They would like a digital signature from the signaling initiator that > can be checked at every node along the path. (Never mind the CPU cost > of that... ;-( ) Unfortunately, the nature of signaling is that in > general the contents of the signaling -- the SAPU -- changes in some > way from hop to hop along the path. So the best you can do is to sign > the invariant parts of the SAPU -- e.g., the session designation. > There is no other known solution to the general problem of E2E > protection of signaling messages. This is not quite true. Signing each change to the message will solve the general problem of E2E protection of signaling messages. With each change signed, there is no dependence on transitive trust. Steve > This problem arose big time in the active networks research program, > and Sandy Murphy will be first to admit that she didn't solve it. > > Bob Braden > > > *> > _______________________________________________ > *> > nsis mailing list > *> > nsis@ietf.org > *> > https://www1.ietf.org/mailman/listinfo/nsis > *> > *> > *> > *> -------------------------------------- > *> Dr. Marcus Brunner > *> Network Laboratories > *> NEC Europe Ltd. > *> > *> E-Mail: brunner@ccrle.nec.de > *> WWW: http://www.ccrle.nec.de/ > *> Phone: +49 (0) 6221 905 11 29 > *> personal home page: http://www.brubers.org/marcus > *> > *> > *> _______________________________________________ > *> nsis mailing list > *> nsis@ietf.org > *> https://www1.ietf.org/mailman/listinfo/nsis > *> > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 14:28: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 OAA07401 for ; Tue, 5 Nov 2002 14:28:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5JURo03137 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 14:30: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 gA5JUOv03129; Tue, 5 Nov 2002 14:30: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 gA5JTiv03095 for ; Tue, 5 Nov 2002 14:29:44 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07350 for ; Tue, 5 Nov 2002 14:27:11 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA5JTaa28080; Tue, 5 Nov 2002 11:29:36 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id TAA04713; Tue, 5 Nov 2002 19:29:36 GMT Date: Tue, 5 Nov 2002 19:29:36 GMT Message-Id: <200211051929.TAA04713@gra.isi.edu> To: nsis@ietf.org, robert.hancock@roke.co.uk Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> Hi all, *> *> I think there is a general point about several of these requirements, in that at this stage we could be saying (e.g. for a MUST) *> *) mandatory to SPECIFY in the protocol definition, or *> *) mandatory to IMPLEMENT in an implementation of it, or *> *) mandatory to USE in a deployment of an implementation *> *> Is it useful to draw this distinction more formally somehow? Or is everything clearly only SPECIFY at this stage (and the rest depends on what the protocol ends up being?) *> *> robert h. *> Robert, I believe that the purpose of the requirements document requested by the ADs is to define the requirements for the protocol spcification. That rules out the second and third of your categories. The second category, IMPLEMENT, would come in an Applicability Statement document (which has often been called a "requirements" document too, somewhat confusingly). In practice, however, many protocol specs include applicability statements interleaved with the technical specification. The IETF clearly has nothing to say about USE. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 14: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 OAA08577 for ; Tue, 5 Nov 2002 14:47:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5Jn8104513 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 14:49: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 gA5Jn4v04506; Tue, 5 Nov 2002 14:49: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 gA5Jmcv04487 for ; Tue, 5 Nov 2002 14:48:38 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08442 for ; Tue, 5 Nov 2002 14:46:05 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA5JmVa09757; Tue, 5 Nov 2002 11:48:31 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id TAA04732; Tue, 5 Nov 2002 19:48:30 GMT Date: Tue, 5 Nov 2002 19:48:30 GMT Message-Id: <200211051948.TAA04732@gra.isi.edu> To: braden@ISI.EDU, nsis@ietf.org, brunner@ccrle.nec.de Subject: Re: [NSIS] Req-Draft: Open Issue 2: Independence of reservation identifier X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> From brunner@ccrle.nec.de Tue Nov 5 05:39:02 2002 *> Date: Tue, 05 Nov 2002 14:38:16 +0100 *> From: Marcus Brunner *> To: Bob Braden , nsis@ietf.org *> Subject: Re: [NSIS] Req-Draft: Open Issue 2: Independence of reservation *> identifier *> MIME-Version: 1.0 *> Content-Transfer-Encoding: 7bit *> Content-Disposition: inline *> X-AntiVirus: scanned by AMaViS 0.2.1 *> *> Bob, *> *> Just for clarification. Is the emphesis on the independence the problem? Or *> is the reservation ID itself the problem? Marcus, The first, in general. *> *> So reformulating the requirement into "An NSIS protocol MUST support a *> reservation identifer" would solve the first one. OK, although I would say "MUST be able to support". BTW, a reservation identifier is presumably a multi-hop thing, so in my 2-level model it is a creature of ULSP, i.e., it is carried in an SAPU. That's good, because non-QoS signaling applications probably don't have any reservations to identify. Ooops, your requirement only applies to QoS signaling. Is that appropriate? *> The reservation *> identifier then can be the same as the flow id or can be something else. I am not sure I understand this last sentence above. I understand "flow id" as we have been using it to mean the set of header fields that define the flow. If it is a microflow, this generally includes the source and destination IP addresses and the source and destination ports, and perhaps the IP protocol number. A reservation identifier is presumably a single number from some distinct number space; I am not sure what you mean by "the same as". Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 14:50: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 OAA08767 for ; Tue, 5 Nov 2002 14:50:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5Jq5J04655 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 14:52:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5Jq3v04646; Tue, 5 Nov 2002 14:52: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 gA5JpLv04618 for ; Tue, 5 Nov 2002 14:51:21 -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 OAA08702 for ; Tue, 5 Nov 2002 14:48:48 -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 gA5Jp9PP011755; Tue, 5 Nov 2002 11:51:09 -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 AAR39928; Tue, 5 Nov 2002 11:46:24 -0800 (PST) Message-Id: <200211051946.AAR39928@mira-sjc5-4.cisco.com> To: brunner@ccrle.nec.de cc: Hannes.Tschofenig@siemens.com, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Open Issues: Peer-to-Peer Protection In-Reply-To: Message from Marcus Brunner of "Tue, 05 Nov 2002 15:05:13 +0100." <19028131.1036508713@[192.168.102.207]> Date: Tue, 05 Nov 2002 14:51:07 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > I am not sure what we need to protect end-to-end can you give some example > applications for other then peer-to-peer It's possible - likely, even - that there are applications in which a resource allocation decision depends on the authenticated identity of the NSIS initiator or other identity information in the packet, or requires that the request be authenticated cryptographically using the key of the originator. In this case I would say that there's likely to be a need to provide end-to-something protection, where "protection" means "authentication." This, however, is almost certainly an NSIS application requirement and not an NSIS transport layer requirement. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 5 15:18: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 PAA10943 for ; Tue, 5 Nov 2002 15:18:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA5KKFv06387 for nsis-archive@odin.ietf.org; Tue, 5 Nov 2002 15:20:15 -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 gA5KK9v06330; Tue, 5 Nov 2002 15:20: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 gA5KHuv06173 for ; Tue, 5 Nov 2002 15:17:56 -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 PAA10722 for ; Tue, 5 Nov 2002 15:15:23 -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 gA5KHoPP000076; Tue, 5 Nov 2002 12:17:50 -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 AAR41192; Tue, 5 Nov 2002 12:13:04 -0800 (PST) Message-Id: <200211052013.AAR41192@mira-sjc5-4.cisco.com> To: "Hancock, Robert" cc: nsis@ietf.org From: Melinda Shore In-Reply-To: Message from "Hancock, Robert" of "Mon, 04 Nov 2002 19:58:34 GMT." <76C92FBBFB58D411AE760090271ED41805DF5D26@rsys002a.roke.co.uk> Date: Tue, 05 Nov 2002 15:17:47 -0500 Subject: [NSIS] Re: sender/receiver initiation (was: RE: Comments on framework draft) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > Actually, I'm not sure why this impression is given: the > basic point is that there is no assumed relationship of > NI/NR w.r.t. data sender or receiver. If the NI is at (or > near) the sender, 4.2 and 4.3.2 are describing > sender-oriented signallng, but not if it is at the > receiver. (Maybe it should be emphasised earlier?) I think so - like it or not we do have an existing understanding of "sender" and "receiver" that's based on RSVP, and if we're going to use the terms differently that difference needs to be described clearly. This also explains why I thought your definitions of receiver- initiated and sender-initiated signaling were nuxied. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 02:45: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 CAA08015 for ; Wed, 6 Nov 2002 02:45:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA67lLU22788 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 02:47:21 -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 gA67lJv22776; Wed, 6 Nov 2002 02:47: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 gA67kOv22738 for ; Wed, 6 Nov 2002 02:46:24 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07982 for ; Wed, 6 Nov 2002 02:43:45 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 6 Nov 2002 08:45:38 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Nov 2002 08:45:32 +0100 Message-Id: From: "Geib, Ruediger" To: robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Wed, 6 Nov 2002 08:45:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA67kPv22739 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > 2. ability to avoid someone stealing the reservation (my > emphasis). here, there is a difference, of a 'soft' sort. That's what I'm interested in too. Regards, Rüdiger > > Robert > > > > > well, the question as i understood it was: isn't using a flow > > > id (=, in framework terminology, some address fields/ports > > > and so on) just as insecure as a reservation identifier? > > > > You got my question. > > > > > answer: no, because the behaviour of the network ties the > > > flow id (non-cryptographically) to the relevant parties (flow > > > endpoints) - which is what the referred-to message asserts - > > > whereas the reservation id (to be useful) is independent of > > > any such constraint or guarantee. > > > > The reservation ID is visible on signaling application level. > > I'd expect a signaling node to save state, including the > > relevant flow information. So the flow context is > > re-established by means of the reservation ID. Then the > > signaling node has the same information as with a flow ID, > > doesn't it? > > > > Changing IP addresses obviously require signaling of a > > new flow ID. > > > > I think the signaling load may be reduced by a reservation ID. > > You trade that for an additional soft state entry in the router > > (the reservation ID). > > > > I didn't explain the above prior to this message. I don't > > think this is less secure than repeating the flow ID on > > signaling application level. > > > > Regards, Rüdiger > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 02:49: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 CAA08121 for ; Wed, 6 Nov 2002 02:49:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA67q5k23090 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 02:52:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA67q3v23083; Wed, 6 Nov 2002 02:52: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 gA67pdv23064 for ; Wed, 6 Nov 2002 02:51:39 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08116 for ; Wed, 6 Nov 2002 02:48:59 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA67p0O12459 for ; Wed, 6 Nov 2002 09:51:00 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Nov 2002 09:51:25 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 09:51:25 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 09:51:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Wed, 6 Nov 2002 09:51:24 +0200 Message-ID: Thread-Topic: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Thread-Index: AcKFaL8t5cqU8eYNSi+m8Gw9g4UyFgAABwEw To: , Cc: X-OriginalArrivalTime: 06 Nov 2002 07:51:25.0551 (UTC) FILETIME=[4E89CFF0:01C28569] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA67pdv23065 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, So, we have the following needs: 1) Potential confidentiality of data 2) Protection against DoS attacks 3) Ensuring reservation ownership (this is applicable for QoS, NAT / firewall traversal) I'd suggest that 1) is a MUST at the application signaling layer 2) is a MUST in a general sense 3) is a MUST in a general sense John > -----Original Message----- > From: ext Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 06 November, 2002 09:46 > To: robert.hancock@roke.co.uk > Cc: nsis@ietf.org > Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of > reservation > i dentifier > > > > 2. ability to avoid someone stealing the reservation (my > > emphasis). here, there is a difference, of a 'soft' sort. > > That's what I'm interested in too. > > Regards, Rüdiger > > > > Robert > > > > > > > well, the question as i understood it was: isn't using a flow > > > > id (=, in framework terminology, some address fields/ports > > > > and so on) just as insecure as a reservation identifier? > > > > > > You got my question. > > > > > > > answer: no, because the behaviour of the network ties the > > > > flow id (non-cryptographically) to the relevant parties (flow > > > > endpoints) - which is what the referred-to message asserts - > > > > whereas the reservation id (to be useful) is independent of > > > > any such constraint or guarantee. > > > > > > The reservation ID is visible on signaling application level. > > > I'd expect a signaling node to save state, including the > > > relevant flow information. So the flow context is > > > re-established by means of the reservation ID. Then the > > > signaling node has the same information as with a flow ID, > > > doesn't it? > > > > > > Changing IP addresses obviously require signaling of a > > > new flow ID. > > > > > > I think the signaling load may be reduced by a reservation ID. > > > You trade that for an additional soft state entry in the router > > > (the reservation ID). > > > > > > I didn't explain the above prior to this message. I don't > > > think this is less secure than repeating the flow ID on > > > signaling application level. > > > > > > Regards, Rüdiger > > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 02:56: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 CAA08203 for ; Wed, 6 Nov 2002 02:56:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA67wCA23312 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 02:58: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 gA67w9v23303; Wed, 6 Nov 2002 02:58: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 gA67vnv23278 for ; Wed, 6 Nov 2002 02:57:49 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08170 for ; Wed, 6 Nov 2002 02:55:10 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA67vBO17554 for ; Wed, 6 Nov 2002 09:57:11 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Nov 2002 09:57:36 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 09:57:36 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 09:57:36 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 09:57:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation identifier Date: Wed, 6 Nov 2002 09:57:35 +0200 Message-ID: Thread-Topic: [NSIS] Req-Draft: Open Issue 2: Independence of reservation identifier Thread-Index: AcKEqRhmFEsQ8EI0RWCpbz8vYudo7QAwJpQQ To: Cc: X-OriginalArrivalTime: 06 Nov 2002 07:57:36.0037 (UTC) FILETIME=[2B5D7D50:01C2856A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA67vnv23279 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Rüdiger, > I'd like to to keep a reservation ID as a requirement and > I prefer to look at it as a "must" (no capitals). Two > issues: it may save signaling load if you refresh by using > reservation IDs instead of flow IDs. That may be > intersting on wireless interfaces, but not only there. > The other argument I see is aggregation. I'm aware of > RFC 3175 and I regard the aggregation > mechanism designed there as smart but non trivial. A > reservation ID may be useful in this context. > > I've twice used "may" here. It would be great if could > decide on the strength of requirement (must, should, may) > after we checked some real world designs and a proof of > concept. I think the concept is a good one, but I somehow feel funny that it would be a 'requirement' - perhaps it could listed as a SHOULD or 'SHOULD be considered' - would that work? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 03:17: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 DAA08622 for ; Wed, 6 Nov 2002 03:17:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA68JKC24657 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 03:19: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 gA68JIv24633; Wed, 6 Nov 2002 03:19: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 gA68FAv24450 for ; Wed, 6 Nov 2002 03:15:10 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08520 for ; Wed, 6 Nov 2002 03:12:31 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 6 Nov 2002 09:13:43 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Nov 2002 09:13:43 +0100 Message-Id: From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Wed, 6 Nov 2002 09:13:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA68FAv24451 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi John, "SHOULD" is ok. "To be considered" sounds a bit too weak. Regards, Rüdiger > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, November 06, 2002 8:58 AM > To: Geib, Rüdiger > Cc: nsis@ietf.org > Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of > reservation > identifier > > > Hi Rüdiger, > > > I'd like to to keep a reservation ID as a requirement and > > I prefer to look at it as a "must" (no capitals). Two > > issues: it may save signaling load if you refresh by using > > reservation IDs instead of flow IDs. That may be > > intersting on wireless interfaces, but not only there. > > The other argument I see is aggregation. I'm aware of > > RFC 3175 and I regard the aggregation > > mechanism designed there as smart but non trivial. A > > reservation ID may be useful in this context. > > > > I've twice used "may" here. It would be great if could > > decide on the strength of requirement (must, should, may) > > after we checked some real world designs and a proof of > > concept. > > I think the concept is a good one, but I somehow feel funny > that it would be a 'requirement' - perhaps it could listed > as a SHOULD or 'SHOULD be considered' - would that work? > > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 03: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 DAA08635 for ; Wed, 6 Nov 2002 03:17:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA68JOh24681 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 03:19: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 gA68JKv24649; Wed, 6 Nov 2002 03:19: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 gA68G3v24496 for ; Wed, 6 Nov 2002 03:16:03 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08541 for ; Wed, 6 Nov 2002 03:13:24 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA68FQO06283 for ; Wed, 6 Nov 2002 10:15:26 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Nov 2002 10:15:51 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 10:15:51 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 10:15:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation identifier Date: Wed, 6 Nov 2002 10:15:44 +0200 Message-ID: Thread-Topic: [NSIS] Req-Draft: Open Issue 2: Independence of reservation identifier Thread-Index: AcKFbJpMQQvAXf76RQG4V6hMfuXG0wAAAjoA To: Cc: X-OriginalArrivalTime: 06 Nov 2002 08:15:50.0785 (UTC) FILETIME=[B7E2C710:01C2856C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA68G3v24497 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Rüdiger, > "SHOULD" is ok. "To be considered" sounds a bit too weak. SHOULD or SHOULD be considered were my suggestions. Either are OK with me. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 03:22: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 DAA08812 for ; Wed, 6 Nov 2002 03:22:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA68Osh25033 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 03:24: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 gA68Opv25025; Wed, 6 Nov 2002 03:24:51 -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 gA68NMv24934 for ; Wed, 6 Nov 2002 03:23:22 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08755 for ; Wed, 6 Nov 2002 03:20:42 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 6 Nov 2002 09:22:30 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Nov 2002 09:22:30 +0100 Message-Id: From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Wed, 6 Nov 2002 09:22:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA68NMv24935 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello John, sorry for giving an ambiguous reply. The first "SHOULD" (i.e. not "SHOULD be considered") is what I prefer. Regards, Rüdiger > > "SHOULD" is ok. "To be considered" sounds a bit too weak. > > SHOULD or SHOULD be considered were my suggestions. Either are > OK with me. > > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 04:07: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 EAA09756 for ; Wed, 6 Nov 2002 04:07:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA699dP28496 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 04:09:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA699bv28489; Wed, 6 Nov 2002 04:09: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 gA698iv28463 for ; Wed, 6 Nov 2002 04:08:44 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09738 for ; Wed, 6 Nov 2002 04:06:04 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA6986O27093 for ; Wed, 6 Nov 2002 11:08:06 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 6 Nov 2002 11:08:31 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 11:08:31 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 11:08:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 6 Nov 2002 11:08:30 +0200 Message-ID: Thread-Topic: [NSIS] Req-Draft: Open Issue 2: Independence of reservation identifier Thread-Index: AcKEpsxKJwZvNGc4Qe+m/lav88oR4QAy7hzA To: X-OriginalArrivalTime: 06 Nov 2002 09:08:31.0370 (UTC) FILETIME=[13BDC6A0:01C28574] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA698iv28464 Subject: [NSIS] IETF 55 Meeting Agenda proposal Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, Here is my first shot at an agenda. What I would like is to spend most of the first session trying to get a handle on some issues, discuss how to procede and try to settle the requirements document. If anyone has any issues that they feel should be discussed, please let me know. thanks, John Tuesday November 19, 2002 1300-1400 Afternoon Session I WG Status, charter discussion - chair 30 min Requirements - Marcus Brunner - 30 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-05.txt WEDNESDAY, November 20, 2002 0900-1130 Morning Sessions Framework Discussion - 60 minutes intro - chair 10 minutes Next Steps in Signaling: Framework - Robert Handcock - (15 min) http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-00.txt Trade-offs and open issues with path discovery and transport - Henning Schulzrinne - (15 min) A Two-Level Architecture for Internet Signaling - chair - (10 min) http://www.ietf.org/internet-drafts/draft-braden-2level-signaling-01.txt Sender and Receiver Orientation Issues in NSIS - Robert Hancock - (10 min) http://www.ietf.org/internet-drafts/draft-hancock-nsis-sender-receiver-00.txt Analysis work - 30 minutes Analysis of Existing Quality of Service Signaling Protocols - Jukka Manner - (10 min) http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-00.txt Nsis Threats - H. Tschofenig - (10min) http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-00.txt RSVP Security Properties - H. Tschofenig - (10min) http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-00.txt Analysis of Existing QoS Solutions - TBD - (5 min) http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-03.txt Analysis of Mobile IP and RSVP Interactions - TBD - (10 minutes) http://www.ietf.org/internet-drafts/draft-thomas-nsis-rsvp-analysis-00.txt Discusion - (15 min) Solutions - 30 minutes A Proposal for RSVPv2 - Karagiannis (10 min) http://www.ietf.org/internet-drafts/draft-westberg-proposal-for-rsvpv2-01.txt A Firewall/NAT Traversal Client for CASP - H. Tschofenig - (10 min) http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-casp-midcom-00.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 04:09: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 EAA09809 for ; Wed, 6 Nov 2002 04:09:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA69C5H28646 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 04:12:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA69C3v28624; Wed, 6 Nov 2002 04:12: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 gA69Bhv28590 for ; Wed, 6 Nov 2002 04:11:43 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09800 for ; Wed, 6 Nov 2002 04:09:03 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gA69BVr01203; Wed, 6 Nov 2002 10:11:31 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gA69BUB06180; Wed, 6 Nov 2002 10:11:30 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Melinda Shore" , Cc: Subject: RE: [NSIS] Open Issues: Peer-to-Peer Protection Date: Wed, 6 Nov 2002 10:11:47 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200211051946.AAR39928@mira-sjc5-4.cisco.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi melinda! from your text i read that you think that something like end-to-middle authentication should be supported. i agree with you that it is applicable to the nsis application level - not to the transport. ciao hannes > > I am not sure what we need to protect end-to-end can you give > some example > > applications for other then peer-to-peer > > It's possible - likely, even - that there are applications > in which a resource allocation decision depends on the > authenticated identity of the NSIS initiator or other > identity information in the packet, or requires that the > request be authenticated cryptographically using the key of > the originator. In this case I would say that there's > likely to be a need to provide end-to-something protection, > where "protection" means "authentication." This, however, > is almost certainly an NSIS application requirement and not > an NSIS transport layer requirement. > > Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 04:09: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 EAA09822 for ; Wed, 6 Nov 2002 04:09:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA69C8w28658 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 04:12: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 gA69C4v28639; Wed, 6 Nov 2002 04:12: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 gA69Bnv28595 for ; Wed, 6 Nov 2002 04:11:49 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09803 for ; Wed, 6 Nov 2002 04:09:09 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id gA69BUC11247; Wed, 6 Nov 2002 10:11:30 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gA69BUB06162; Wed, 6 Nov 2002 10:11:30 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Steven Berson" , "Bob Braden" Cc: , Subject: RE: [NSIS] Open Issues: Peer-to-Peer Protection Date: Wed, 6 Nov 2002 10:11:47 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi steve, hi bob. please see my comments inline. > > > > Marcus, > > > > I don't think it is so much a matter of need as it is of ability. > > Security wonks always feel uncomfortable about the transitive trust > > model implied by pure hop/hop integrity. They point out that if any > > link in the chain is penetrated, then the whole path is penetrated. > > They would like a digital signature from the signaling initiator that > > can be checked at every node along the path. (Never mind the CPU cost > > of that... ;-( ) a digital signature by the signaling message initiator is not necessarily required. i see that there is a problem with cpu costs etc. > Unfortunately, the nature of signaling is that in > > general the contents of the signaling -- the SAPU -- changes in some > > way from hop to hop along the path. true. some things. some other things don't. So the best you can do is to sign > > the invariant parts of the SAPU -- e.g., the session designation. > > There is no other known solution to the general problem of E2E > > protection of signaling messages. i intentionally avoided the term end-to-end protection. non peer-to-peer protection is not necessary end-to-end protection. you can take a look at the following figure to see the possible options: **************************************** * * * * +----+-----+ +----------+ +----+-----+ +-----+ Router +-------+ Router +--------+ Router +-----+ | | 1 | | 2 | | 3 | | | +----------+ +----+-----+ +----------+ | | ~ | | ~ | | ~ | | ~ | | ~ | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | ~ | | ~ | +--+--++ +--+---+ | Host +//////////////////////////////////////////////////////+ Host | | A | | B | +------+ +------+ Legend: -----: Peer-to-Peer Trust Relationship /////: End-to-End Trust Relationship *****: Middle-to-Middle Trust Relationship ~~~~~: End-to-Middle Trust Relationship i intentionally avoided the term end-to-end protection. non peer-to-peer protection is not necessary end-to-end protection. for example: the rsvp integrity object is used in two places: a) to protect the entire rsvp message (=peer-to-peer security) b) to protect the policy object (=something other than peer-to-peer). another example: protecting local information authorization tokens would be another form of non peer-to-peer protection. whether to have support for end-to-end protection is a different issue. i argue that you do not need to have end-to-end security because the protocol behavior (e.g. proxy behavior, acting on behalf of someone else, initiating signaling message everywhere, modification of messages along the path, etc.) might not be simply possible. if some sort of end-to-end negotiation should take place then this could experience e2e protection. i tend to avoid e2e security protection. pure end-to-end issues should be done with end-to-end protocols (not with nsis). > This is not quite true. Signing each change to the message will solve > the general problem of E2E protection of signaling messages. With > each change signed, there is no dependence on transitive trust. depending on the protocol behavior this creates a solution which is not scalable and a performance disaster. > > Steve > > > This problem arose big time in the active networks research program, > > and Sandy Murphy will be first to admit that she didn't solve it. > > > > Bob Braden ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 05:29: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 FAA10815 for ; Wed, 6 Nov 2002 05:29:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6AVJt32730 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 05:31:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6AVHv32719; Wed, 6 Nov 2002 05:31: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 gA6AUuv32673 for ; Wed, 6 Nov 2002 05:30:56 -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 FAA10806 for ; Wed, 6 Nov 2002 05:28:26 -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 gA6AUtY97948; Wed, 6 Nov 2002 11:30:55 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 021FC6687A; Wed, 6 Nov 2002 11:30:21 +0100 (CET) Date: Wed, 06 Nov 2002 11:30:22 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Bob Braden , nsis@ietf.org Subject: Re: [NSIS] Req-Draft: Open Issue 2: Independence of reservation identifier Message-ID: <3976588.1036582222@[192.168.102.207]> In-Reply-To: <200211051948.TAA04732@gra.isi.edu> References: <200211051948.TAA04732@gra.isi.edu> X-Mailer: Mulberry/2.2.0 (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: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > BTW, a reservation identifier is presumably a multi-hop thing, so in my > 2-level model it is a creature of ULSP, i.e., it is carried in an > SAPU. That's good, because non-QoS signaling applications probably > don't have any reservations to identify. > > Ooops, your requirement only applies to QoS signaling. Is that > appropriate? > I would think all applications do have to identify a reservation (state), otherwise you do not need signaling at all. And I don't see why it should apply to QoS signaling. Do you see this in the req text? > *> The reservation > *> identifier then can be the same as the flow id or can be something > else. > > I am not sure I understand this last sentence above. I understand "flow > id" as we have been using it to mean the set of header fields that define > the flow. If it is a microflow, this generally includes the source and > destination IP addresses and the source and destination ports, and perhaps > the IP protocol number. A reservation identifier is presumably a single > number from some distinct number space; I am not sure what you mean by > "the same as". > > Bob And the number space for the reservation id could be 5-dimensionl containing src/dest addr, ports, and proto number, but it can also be derived from any other information or chosen randomly etc. I regard this then a protocol specification task to define what the reservation id is. Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 05:35: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 FAA10895 for ; Wed, 6 Nov 2002 05:35:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6Ab6b00532 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 05:37: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 gA6Ab4v00461; Wed, 6 Nov 2002 05:37: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 gA6Aamv00394 for ; Wed, 6 Nov 2002 05:36:48 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10877 for ; Wed, 6 Nov 2002 05:34:18 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gA6Aakr04827 for ; Wed, 6 Nov 2002 11:36:46 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail3.siemens.de (8.11.6/8.11.6) with SMTP id gA6AakQ03036 for ; Wed, 6 Nov 2002 11:36:46 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: Date: Wed, 6 Nov 2002 11:37:02 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Subject: [NSIS] Req-Draft: Open Issue 5 Req 5.7.10 Hooks ... Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi marcus raised the question what todo with this paragraph. there are the following options: a) drop it (without replacement) b) replace it by something more concise c) move it to the framework i would like to get an idea what people think about the possible interaction between nsis and key management protocols. i personally think that key management is an important topic and should be addressed in the requirements somehow. ciao hannes > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Hannes Tschofenig > Sent: Monday, November 04, 2002 6:12 PM > To: brunner@ccrle.nec.de; nsis@ietf.org > Subject: RE: [NSIS] Req-Draft: Open Issue 5 Req 5.7.10 Hooks ... > > > hi marcus > > i think that nsis should be able to interact with other protocols (called > hooks in this context). other protocols also require such interaction. to > make sure that the interaction is actually possible (and that it works in > the expected way) a requirement should be specified. is the descripion too > fuzzy? should it simply be discussed in the framework only? > > ciao > hannes > > > -----Original Message----- > > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > > Marcus Brunner > > Sent: Friday, November 01, 2002 11:37 PM > > To: nsis@ietf.org > > Subject: [NSIS] Req-Draft: Open Issue 5 Req 5.7.10 Hooks ... > > > > > > Req-Draft: Open Issue 5 Req 5.7.10 Hooks ... > > -------------------------------------------- > > > > Proposal to remove req 5.7.10 " Hooks with Authentication and Key > > Agreement > > protocols" > > > > 5.7.10 Hooks with Authentication and Key Agreement protocols > > > > This requirement covers two subsequent steps before a signaling > > protocol is > > executed and the required hooks. First there is a need to agree on a > > specific authentication protocol. Later this protocol is executed and > > provides authentication and establishes the desired security > > associations. > > Using these security associations it is then possible to > exchange secured > > signaling messages. > > > > The signaling protocol implementation SHOULD provide hooks to > > interact with > > protocols that allow the negotiation of authentication and key agreement > > protocols. Although the negotiation of an authentication and key > > management > > protocol within the signaling protocol may be outside the scope > > it is still > > required to trigger this exchange in case that no such security > > association > > is available. > > This requirement originates from the fact that more than one key > > management > > protocol may be used to provide a security association for the signaling > > protocol. Hence the communicating entities must be capable to agree on a > > specific authentication. The selected authentication and key agreement > > protocol must however be able to create a security association > > that can be > > used within the signaling protocol. > > > > Key management protocols typically require a larger number of > messages to > > be transmitted to allow a session key and the corresponding security > > association to be derived. To avoid the complex issue of embedding > > individual authentication and key agreement protocols into a specific > > signaling protocol it is required that most of these protocols > > are executed > > independently (prior to the signaling protocol) and although the key > > management protocol may be independent there must be a way for the > > signaling protocol to access and use available (i.e. already > established) > > security associations to avoid executing a separate key > > management protocol > > (or instance of the same protocol) for protocols that closely operate > > together. If no such security association exists then there > > SHOULD be means > > for the signaling protocol to dynamically trigger such a protocol. > > > > > > > > > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > Phone: +49 (0) 6221 905 11 29 > > personal home page: http://www.brubers.org/marcus > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 05:41: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 FAA10969 for ; Wed, 6 Nov 2002 05:41:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6Ah8X01229 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 05:43: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 gA6Ah6v01218; Wed, 6 Nov 2002 05: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 gA6Ag3v01172 for ; Wed, 6 Nov 2002 05:42:03 -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 FAA10951 for ; Wed, 6 Nov 2002 05:39:33 -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 gA6Ag1Y98353; Wed, 6 Nov 2002 11:42:01 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 437CF2F576; Wed, 6 Nov 2002 11:41:28 +0100 (CET) Date: Wed, 06 Nov 2002 11:41:29 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] IETF 55 Meeting Agenda proposal Message-ID: <4643987.1036582889@[192.168.102.207]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I don't think we should go to solutions already. Marcus > Solutions - 30 minutes > > A Proposal for RSVPv2 - Karagiannis (10 min) > http://www.ietf.org/internet-drafts/draft-westberg-proposal-for-rsvpv2-0 > 1.txt > > A Firewall/NAT Traversal Client for CASP - H. Tschofenig - (10 min) > http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-casp-midcom-00 > .txt _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 05: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 FAA11000 for ; Wed, 6 Nov 2002 05:43:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6Aj7401315 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 05:45: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 gA6Aj2v01307; Wed, 6 Nov 2002 05:45: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 gA6Aicv01260 for ; Wed, 6 Nov 2002 05:44:38 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10988 for ; Wed, 6 Nov 2002 05:42:07 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA6Ai6O23440 for ; Wed, 6 Nov 2002 12:44:06 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Nov 2002 12:44:30 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 12:44:30 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 12:44:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] IETF 55 Meeting Agenda proposal Date: Wed, 6 Nov 2002 12:44:29 +0200 Message-ID: Thread-Topic: [NSIS] IETF 55 Meeting Agenda proposal Thread-Index: AcKFgSio+8XdyJsxSBWNk14mbjrgjwAACQFg To: , X-OriginalArrivalTime: 06 Nov 2002 10:44:30.0558 (UTC) FILETIME=[7C7C1FE0:01C28581] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA6Aicv01261 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Marcus, > I don't think we should go to solutions already. I agree - that is why if there are any discussions of solution-oriented drafts, then the discussion topics open would be issues that could/should be considered by existing WG drafts. There is no presentation of the actual solutions at IETF 55. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 05:46: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 FAA11097 for ; Wed, 6 Nov 2002 05:46:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6Am7b01455 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 05:48: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 gA6Am4v01444; Wed, 6 Nov 2002 05:48: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 gA6AlOv01406 for ; Wed, 6 Nov 2002 05:47:24 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11075 for ; Wed, 6 Nov 2002 05:44:53 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 6 Nov 2002 11:46:15 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Nov 2002 11:46:12 +0100 Message-Id: From: "Geib, Ruediger" To: brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Wed, 6 Nov 2002 11:46:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA6AlOv01408 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Marcus, > And the number space for the reservation id could be 5-dimensionl > containing src/dest addr, ports, and proto number... Yes, that's kind of the largest possible reservation ID. > but it can also be derived from any other information > or chosen randomly etc. I disagree. The reservation ID must be non ambiguous. A part of it may be assigned randomly. A simple solution may be reservation ID = source address + random number. Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 06:16: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 GAA11579 for ; Wed, 6 Nov 2002 06:16:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6BIAJ03220 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 06:18:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6BI8v03213; Wed, 6 Nov 2002 06:18: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 gA6BH3v03156 for ; Wed, 6 Nov 2002 06:17:03 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11565 for ; Wed, 6 Nov 2002 06:14:33 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA6BH1Q1012736; Wed, 6 Nov 2002 12:17:01 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WJR9DH0X; Wed, 6 Nov 2002 12:17:01 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Nov 2002 12:17:00 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE181@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 72a19186 ca231590 5b417197 00000138 From: "Georgios Karagiannis (ELN)" To: "'brunner@ccrle.nec.de'" , nsis@ietf.org Cc: john.loughney@nokia.com Subject: RE: [NSIS] IETF 55 Meeting Agenda proposal Date: Wed, 6 Nov 2002 12:16:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Marcus In the "A Proposal for RSVPv2" presentation I will only focus on the applied concept, that is an extension of the concept described in draft-braden-2level-signaling-01.txt. Thus I will not present the solution but I will only present the applied concept! Therefore, I would very much appreciate to use the assigned time slot! John I could send you the slides before the meeting for review! Best Regards, Georgios -----Original Message----- From: Marcus Brunner [mailto:brunner@ccrle.nec.de] Sent: woensdag 6 november 2002 11:41 To: john.loughney@nokia.com; nsis@ietf.org Subject: Re: [NSIS] IETF 55 Meeting Agenda proposal I don't think we should go to solutions already. Marcus > Solutions - 30 minutes > > A Proposal for RSVPv2 - Karagiannis (10 min) > http://www.ietf.org/internet-drafts/draft-westberg-proposal-for-rsvpv2-0 > 1.txt > > A Firewall/NAT Traversal Client for CASP - H. Tschofenig - (10 min) > http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-casp-midcom-00 > .txt _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 06:44: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 GAA13523 for ; Wed, 6 Nov 2002 06:44:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6Bk6905481 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 06:46: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 gA6Bk4v05472; Wed, 6 Nov 2002 06:46: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 gA6BXTv03964 for ; Wed, 6 Nov 2002 06:33:29 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12554; Wed, 6 Nov 2002 06:30:58 -0500 (EST) Message-Id: <200211061130.GAA12554@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 06 Nov 2002 06:30:58 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-req-05.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling 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 Next Steps in Signaling Working Group of the IETF. Title : Requirements for Signaling Protocols Author(s) : M. Brunner Filename : draft-ietf-nsis-req-05.txt Pages : 36 Date : 2002-11-5 This document defines requirements for signaling across different network environments, where different network environments mean across administrative and technology domains. Signaling is mainly though for QoS such as [RSVP], however in recent year several other applications of signaling have been defined such as signaling for MPLS label distribution [RSVP-TE]. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. This memo present the assumptions and the aspects not considered within scope before listing the requirements grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-05.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-nsis-req-05.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-nsis-req-05.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-5193420.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-req-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-req-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-5193420.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 07:06: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 HAA14408 for ; Wed, 6 Nov 2002 07:06:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6C8Dl07118 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 07:08: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 gA6C88v07103; Wed, 6 Nov 2002 07:08: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 gA6C76v06703 for ; Wed, 6 Nov 2002 07:07:06 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14373 for ; Wed, 6 Nov 2002 07:04:35 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id gA6C73410181; Wed, 6 Nov 2002 13:07:03 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail3.siemens.de (8.11.6/8.11.6) with SMTP id gA6C73Q00941; Wed, 6 Nov 2002 13:07:03 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: , , Subject: RE: [NSIS] IETF 55 Meeting Agenda proposal Date: Wed, 6 Nov 2002 13:08:20 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <4643987.1036582889@[192.168.102.207]> Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi marcus, hi john i fully agree with you both that we should give a presentation of problems and open issues which go beyond a particular solution. my presentation aims to point to the problems of (missing) trust relationships of in-path signaling (especially in the area of firewall traversal). i think that these issues are also of interest for the question: is peer-to-peer protection sufficient for nsis? it also addresses security problems when signaling is applied only at local networks (at both access networks). ciao hannes > I don't think we should go to solutions already. > Marcus > > > Solutions - 30 minutes > > > > A Proposal for RSVPv2 - Karagiannis (10 min) > > > http://www.ietf.org/internet-drafts/draft-westberg-proposal-for-rsvpv2-0 > > 1.txt > > > > A Firewall/NAT Traversal Client for CASP - H. Tschofenig - (10 min) > > http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-casp-midcom-00 > .txt _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 07:07: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 HAA14448 for ; Wed, 6 Nov 2002 07:07:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6C93507164 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 07:09: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 gA6C91v07157; Wed, 6 Nov 2002 07:09: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 gA6C8sv07142 for ; Wed, 6 Nov 2002 07:08:54 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14427 for ; Wed, 6 Nov 2002 07:06:23 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA6C8PO07237 for ; Wed, 6 Nov 2002 14:08:25 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 6 Nov 2002 14:08:50 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 14:08:49 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 14:08:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 6 Nov 2002 14:08:48 +0200 Message-ID: Thread-Topic: [NSIS] IETF 55 Meeting Agenda proposal Thread-Index: AcKFjQijKEZki9UcR2uj+oeJVRsNDgAAAwzQ To: X-OriginalArrivalTime: 06 Nov 2002 12:08:49.0602 (UTC) FILETIME=[43E8FA20:01C2858D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA6C8sv07143 Subject: [NSIS] IETF 55 Meeting Material Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, I ask the presentors to provide your slidesets prior to the meeting. Please send your slideset by November 16th. This is needed so that the slides can be made available folks who can't attend the meeting. br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 07:10: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 HAA14498 for ; Wed, 6 Nov 2002 07:10:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6CC7507282 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 07:12: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 gA6CC2v07273; Wed, 6 Nov 2002 07:12: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 gA6CBev07254 for ; Wed, 6 Nov 2002 07:11:40 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14474 for ; Wed, 6 Nov 2002 07:09:08 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA6CBBO09192 for ; Wed, 6 Nov 2002 14:11:11 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Nov 2002 14:11:36 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 14:11:34 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 14:11:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 6 Nov 2002 14:11:33 +0200 Message-ID: Thread-Topic: [NSIS] IETF 55 Meeting Agenda proposal Thread-Index: AcKFjQijKEZki9UcR2uj+oeJVRsNDgAAFqmw To: , , X-OriginalArrivalTime: 06 Nov 2002 12:11:33.0957 (UTC) FILETIME=[A5DF8F50:01C2858D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA6CBev07255 Subject: [NSIS] IETF 55 Meeting - discussion of solutions Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, Just to highlight this - we are not going to be talking about solutions at the IETF meeting. However, if anyone working on solutions has discovered some interesting things which the WG should be aware of to help progress the existing set of documents, then that is a valid discussion topic. As all folks presenting a list of discussion points MUST send their slides to me prior to the meeting, that will ensure that the discussions stay on topic it. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 10:20: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 KAA25890 for ; Wed, 6 Nov 2002 10:20:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6FMQu20147 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 10:22: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 gA6FMNv20131; Wed, 6 Nov 2002 10:22:23 -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 gA6FLrv20100 for ; Wed, 6 Nov 2002 10:21:53 -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 KAA25817 for ; Wed, 6 Nov 2002 10:19:21 -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 gA6FLnot003640; Wed, 6 Nov 2002 07:21:49 -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 AAR69881; Wed, 6 Nov 2002 07:17:04 -0800 (PST) Message-Id: <200211061517.AAR69881@mira-sjc5-4.cisco.com> To: Hannes.Tschofenig@siemens.com cc: "Bob Braden" , nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Key management In-Reply-To: Message from "Hannes Tschofenig" of "Tue, 05 Nov 2002 09:35:18 +0100." Date: Wed, 06 Nov 2002 10:21:47 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > i agree with you that the key management should be > addressed. the question where the keys come from is > independent from integrity or confidentiality protection. Unfortunately it's not completely independent. For example the reasonable choices for IPSec are IKE, pre-shared keys (which is probably a bad choice for us), or KINK, while for TLS it's PKI. For us the choice of a keying mechanism is going to come down to some combination of 1) what security protocols we use, 2) what our understanding of the relationships among the entities is going to be (i.e. if there's just a few PSKs might be fine, if they're all in the same domain KINK might be fine, etc.), and so on. I think that at this point the most helpful thing would be to identify the elements that we'd use as the basis for a later decision about keying. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 6 10:29: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 KAA26670 for ; Wed, 6 Nov 2002 10:29:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA6FV9L20782 for nsis-archive@odin.ietf.org; Wed, 6 Nov 2002 10:31:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6FV6v20775; Wed, 6 Nov 2002 10:31: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 gA6FUAv20717 for ; Wed, 6 Nov 2002 10:30:10 -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 KAA26554 for ; Wed, 6 Nov 2002 10:27: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 gA6FU6ot007811; Wed, 6 Nov 2002 07:30:06 -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 AAR70053; Wed, 6 Nov 2002 07:25:21 -0800 (PST) Message-Id: <200211061525.AAR70053@mira-sjc5-4.cisco.com> To: "Geib, Ruediger" cc: Hannes.Tschofenig@siemens.com, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages In-Reply-To: Message from "Geib, Ruediger" of "Tue, 05 Nov 2002 15:19:29 +0100." Date: Wed, 06 Nov 2002 10:30:04 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > To me, a simple relay doesn't have to operate encryption. The correct answer to any technical question is "it depends," and I think it this case it comes down to depending on how the application layer is split from the transport layer, what information is contained in the transport layer, and if the information that a relay would need to forward the message correctly is itself encrypted. My suspicion is that the information one might want to protect from prying eyes will tend to be carried in the application, and that any information that could be derived from looking at transport layer daya could also be derived from traffic analysis. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 07:59: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 HAA19614 for ; Thu, 7 Nov 2002 07:59:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7D16e14796 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 08:01: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 gA7D14v14785; Thu, 7 Nov 2002 08:01: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 gA7Cx8v14627 for ; Thu, 7 Nov 2002 07:59:08 -0500 Received: from msr.hinet.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19450 for ; Thu, 7 Nov 2002 07:56:34 -0500 (EST) Received: from Poo (61-228-76-99.HINET-IP.hinet.net [61.228.76.99]) by msr.hinet.net (8.9.3/8.9.3) with SMTP id UAA25867 for ; Thu, 7 Nov 2002 20:58:33 +0800 (CST) Date: Thu, 7 Nov 2002 20:58:33 +0800 (CST) Message-Id: <200211071258.UAA25867@msr.hinet.net> From: zinin To: nsis@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=U06S5E84jf27z9G2V33j7pg4iQ Subject: [NSIS] Japanese girl VS playboy Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --U06S5E84jf27z9G2V33j7pg4iQ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) index.exe is of type executable and is removed. Please contact your network administrator for further information. --------------------------------------------------------- --U06S5E84jf27z9G2V33j7pg4iQ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --U06S5E84jf27z9G2V33j7pg4iQ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) index.exe is removed from here because it is of type executable --------------------------------------------------------- --U06S5E84jf27z9G2V33j7pg4iQ Content-Type: application/octet-stream; name=index.html Content-Transfer-Encoding: base64 Content-ID: PEhUTUw+PEhFQUQ+PFRJVExFPkFjY29tbW9kYXRpb24gaW4gR2hhbmEgSG90ZWxzLCBHdWVz dCBIb3VzZXMsIEJlZCBhbmQgQnJlYWtmYXN0cywgSW5ucywgTG9kZ2luZ3MsIE1vdGVscywg U2VsZiBjYXRlcmluZyBhY2NvbW1vZGF0aW9uPC9USVRMRT48TUVUQSBOYW1lPSJkZXNjcmlw dGlvbiIgQ29udGVudD0iQWNjb21tb2RhdGlvbiBpbiBHaGFuYSBIb3RlbHMsIEd1ZXN0IEhv dXNlcywgQmVkIGFuZCBCcmVha2Zhc3RzLCBJbm5zLCBMb2RnaW5ncywgTW90ZWxzLCBTZWxm IGNhdGVyaW5nIGFjY29tbW9kYXRpb24iPjxNRVRBIE5hbWU9ImtleXdvcmRzIiBDb250ZW50 PSJHaGFuYSwgaG90ZWxzLCBndWVzdCBob3VzZXMsIGJlZCBhbmQgYnJlYWtmYXN0cywgQiAm IEIsIEImQiwgQiBhbmQgQiwgbG9kZ2luZ3MsIG1vdGVscywgaW5ucywgQUFBLCBhY2NvbW1v ZGF0aW9uLCBhY2NvbW9kYXRpb24sIGFjb21tb2RhdGlvbiI+DQo8L0hFQUQ+PEJPRFkgYmFj a2dyb3VuZD0iLi4vaW1hZ2VzL2hvdGVscy5naWYiIHRwcGFicz0iaHR0cDovL3d3dy5zLWgt c3lzdGVtcy5jby51ay9pbWFnZXMvaG90ZWxzLmdpZiIgQkdDT0xPUj0iI2M2YzZmZiIgVEVY VD0iIzAwMDA2NiI+DQo8QSBOQU1FPSJUT1AiPjwvQT48VEFCTEUgV0lEVEg9IjEwMCUiPjxU Uj48VEQgQUxJR049IkxFRlQiPjxIMT4xLDAwMCdzIG9mIEhvdGVscyBhbmQgR3Vlc3QgSG91 c2VzIFdvcmxkd2lkZS48L0gxPjxCPjxGT05UIFNJWkU9KzI+PEEgSFJFRj0iI0doYW5hX0hv dGVsc19hbmRfR3Vlc3RfSG91c2VzIj5HaGFuYTwvQT48L0ZPTlQ+PEZPTlQgU0laRT0rMT4g SG90ZWxzLCBHdWVzdCBIb3VzZXMgYW5kIFNlbGYgQ2F0ZXJpbmcgQWNjb21tb2RhdGlvbiBt YW55IG9mZmVyaW5nIGV4Y2x1c2l2ZSBTbW9vdGggSG91bmQgZGlzY291bnRzLjwvRk9OVD48 L0I+PC9URD48VEQgVkFMSUdOPSJUT1AiPjxJTUcgU1JDPSIuLi9pbWFnZXMvc2hzbG9nby5q cGciIHRwcGFicz0iaHR0cDovL3d3dy5zLWgtc3lzdGVtcy5jby51ay9pbWFnZXMvc2hzbG9n by5qcGciIFdJRFRIPTE1NCBIRUlHSFQ9MTM3IEJPUkRFUj0xIEFMVD0iU21vb3RoIEhvdW5k IExvZ28iPjwvVEQ+PC9UUj48L1RBQkxFPg0KPEgyIEFMSUdOPSJDRU5URVIiPjxBIE5BTUU9 IlRPUCI+PC9BPlRob3VzYW5kcyBvZiBwbGFjZXMgdG8gc3RheSB3b3JsZC13aWRlLjwvSDI+ PEhSPjxDRU5URVI+PFRBQkxFIEJPUkRFUj0iMSIgQk9SREVSQ09MT1I9IiMwMDAwNjYiPjxU UiBBTElHTj0iQ0VOVEVSIj48VEQgQkdDT0xPUj0iI0ZGRkZGRiI+PEEgSFJFRj0iLi4vd29y bGQuaHRtbCIgdHBwYWJzPSJodHRwOi8vd3d3LnMtaC1zeXN0ZW1zLmNvLnVrL3dvcmxkLmh0 bWwiPjxCPldvcmxkICZndDs8L0I+PC9BPiA8QSBIUkVGPSIuLi9hZnJpY2EuaHRtbCIgdHBw YWJzPSJodHRwOi8vd3d3LnMtaC1zeXN0ZW1zLmNvLnVrL2FmcmljYS5odG1sIj48Qj5BZnJp Y2EgJmd0OzwvQj48L0E+IDxCPkdoYW5hPC9CPjwvVEQ+PC9UUj48L1RBQkxFPjwvQ0VOVEVS PjxIUiBXSURUSD0iNzAlIj48VEFCTEUgV0lEVEg9IjEwMCUiPjxUUiBBTElHTj0iQ0VOVEVS Ij48VEQgV0lEVEg9IjE3JSIgQUxJR049IkNFTlRFUiI+PFRBQkxFIFdJRFRIPSIxMDAlIiBC T1JERVI9IjEiIEJPUkRFUkNPTE9SPSIjMDAwMDY2Ij48VFI+PFREIEFMSUdOPSJDRU5URVIi IEJHQ09MT1I9IiNGRkZGRkYiPjxUQUJMRT48VFI+PFREIEFMSUdOPSJMRUZUIj48SU1HIFdJ RFRIPSI3IiBIRUlHSFQ9IjciIEFMVD0iIiBTUkM9Ii4uL2ltYWdlcy9ob3RlbC1idWxsZXQu Z2lmIiB0cHBhYnM9Imh0dHA6Ly93d3cucy1oLXN5c3RlbXMuY28udWsvaW1hZ2VzL2hvdGVs LWJ1bGxldC5naWYiPjxBIEhSRUY9Ii4uL3VrLWNhci1yZW50YWwvaW5kZXguaHRtbCIgdHBw YWJzPSJodHRwOi8vd3d3LnMtaC1zeXN0ZW1zLmNvLnVrL3VrLWNhci1yZW50YWwvaW5kZXgu aHRtbCI+PEZPTlQgU0laRT0iLTEiPjxCPkNhciBSZW50YWw8L0I+PC9GT05UPjwvQT48QlI+ PElNRyBXSURUSD0iNyIgSEVJR0hUPSI3IiBBTFQ9IiIgU1JDPSIuLi9pbWFnZXMvaG90ZWwt YnVsbGV0LmdpZiIgdHBwYWJzPSJodHRwOi8vd3d3LnMtaC1zeXN0ZW1zLmNvLnVrL2ltYWdl cy9ob3RlbC1idWxsZXQuZ2lmIj48QSBIUkVGPSIuLi93b3JsZC5odG1sIiB0cHBhYnM9Imh0 dHA6Ly93d3cucy1oLXN5c3RlbXMuY28udWsvd29ybGQuaHRtbCI+PEZPTlQgU0laRT0iLTEi PjxCPldvcmxkIFNlYXJjaDwvQj48L0ZPTlQ+PC9BPjxCUj48L1REPjwvVFI+PC9UQUJMRT48 L1REPjwvVFI+PC9UQUJMRT48L1REPjxURCBXSURUSD0iNjYlIiBBTElHTj0iQ0VOVEVSIj48 Qj5QcmVzcyBDVFJMIEQgTk9XISB0byBhZGQgdGhpcyBzaXRlIHRvIHlvdXIgZmF2b3VyaXRl cyE8L0I+PEJSPjxIUiBTSVpFPTMgV0lEVEg9IjcwJSI+PEI+V2VibWFzdGVycyEgPEEgSFJF Rj0iamF2YXNjcmlwdDppZihjb25maXJtKCdodHRwOi8vd3d3LnMtaC1zeXN0ZW1zLmNvLnVr L2xpbmstdG8tc21vb3RoLWhvdW5kLmh0bWwgIFxuXG5UaGlzIGZpbGUgd2FzIG5vdCByZXRy aWV2ZWQgYnkgVGVsZXBvcnQgUHJvLCBiZWNhdXNlIGl0IHdhcyB1bmF2YWlsYWJsZSwgb3Ig aXRzIHJldHJpZXZhbCB3YXMgYWJvcnRlZCwgb3IgdGhlIHByb2plY3Qgd2FzIHN0b3BwZWQg dG9vIHNvb24uICBcblxuRG8geW91IHdhbnQgdG8gb3BlbiBpdCBmcm9tIHRoZSBzZXJ2ZXI/ Jykpd2luZG93LmxvY2F0aW9uPSdodHRwOi8vd3d3LnMtaC1zeXN0ZW1zLmNvLnVrL2xpbmst dG8tc21vb3RoLWhvdW5kLmh0bWwnIiB0cHBhYnM9Imh0dHA6Ly93d3cucy1oLXN5c3RlbXMu Y28udWsvbGluay10by1zbW9vdGgtaG91bmQuaHRtbCI+RW5oYW5jZSBZb3VyIFNpdGUhPC9B PiBBZGQgYSBIb3RlbCBTZWFyY2ghPC9CPjwvVEQ+PFREIFdJRFRIPSIxNyUiPjxUQUJMRSBX SURUSD0iMTAwJSIgQk9SREVSPSIxIiBCT1JERVJDT0xPUj0iIzAwMDA2NiI+PFRSPjxURCBB TElHTj0iQ0VOVEVSIiBCR0NPTE9SPSIjRkZGRkZGIj48VEFCTEU+PFRSPjxURCBBTElHTj0i TEVGVCI+PElNRyBXSURUSD0iNyIgSEVJR0hUPSI3IiBBTFQ9IiIgU1JDPSIuLi9pbWFnZXMv aG90ZWwtYnVsbGV0LmdpZiIgdHBwYWJzPSJodHRwOi8vd3d3LnMtaC1zeXN0ZW1zLmNvLnVr L2ltYWdlcy9ob3RlbC1idWxsZXQuZ2lmIj48YSBocmVmPSIuLi9mcmllbmQuaHRtbCIgdHBw YWJzPSJodHRwOi8vd3d3LnMtaC1zeXN0ZW1zLmNvLnVrL2ZyaWVuZC5odG1sIiBvbmNsaWNr PSJ3aW5kb3cub3BlbigncmVmZXIuaHRtbCcsJ2Fyb21XbmQnLCd3aWR0aD01MzUsaGVpZ2h0 PTIzMCxzY3JvbGxiYXJzPXllcyxtZW51YmFyPW5vLHJlc2l6YWJsZT15ZXMnKTsgcmV0dXJu IGZhbHNlOyIgdGFyZ2V0PSJyZWZlciI+PEZPTlQgU0laRT0iLTEiPjxCPlRlbGwgYSBGcmll bmQ8L0I+PC9GT05UPjwvQT48QlI+PElNRyBXSURUSD0iNyIgSEVJR0hUPSI3IiBBTFQ9IiIg U1JDPSIuLi9pbWFnZXMvaG90ZWwtYnVsbGV0LmdpZiIgdHBwYWJzPSJodHRwOi8vd3d3LnMt aC1zeXN0ZW1zLmNvLnVrL2ltYWdlcy9ob3RlbC1idWxsZXQuZ2lmIj48QSBIUkVGPSIuLi9j b252ZXJ0Lmh0bWwiIHRwcGFicz0iaHR0cDovL3d3dy5zLWgtc3lzdGVtcy5jby51ay9jb252 ZXJ0Lmh0bWwiPjxGT05UIFNJWkU9Ii0xIj48Qj5FeGNoYW5nZSBSYXRlczwvQj48L0ZPTlQ+ PC9BPjxCUj48L1REPjwvVFI+PC9UQUJMRT48L1REPjwvVFI+PC9UQUJMRT48L1REPjwvVFI+ PC9UQUJMRT48QlI+PEEgTkFNRT0iR2hhbmFfSG90ZWxzX2FuZF9HdWVzdF9Ib3VzZXMiPjwv QT48VEFCTEUgV0lEVEg9IjEwMCUiIEJPUkRFUj0iMiIgQk9SREVSQ09MT1I9IiMwMDAwNjYi PjxUUiBBTElHTj0iQ0VOVEVSIj48VEQgQ09MU1BBTj0iNSIgQkdDT0xPUj0iI0ZGRkZGRiIg QUxJR049IkNFTlRFUiI+PEZPTlQgU0laRT0iKzIiPkdoYW5hIC0gUG9wdWxhciBUb3duczwv Rk9OVD48L1REPjwvVFI+PFRSIEFMSUdOPSJDRU5URVIiPjxURCBXSURUSD0iMjAlIj48QSBI UkVGPSJqYXZhc2NyaXB0OmlmKGNvbmZpcm0oJ2h0dHA6Ly93d3cucy1oLXN5c3RlbXMuY28u dWsvZ2hhbmEvYWNjcmEuaHRtbCAgXG5cblRoaXMgZmlsZSB3YXMgbm90IHJldHJpZXZlZCBi eSBUZWxlcG9ydCBQcm8sIGJlY2F1c2UgaXQgd2FzIHVuYXZhaWxhYmxlLCBvciBpdHMgcmV0 cmlldmFsIHdhcyBhYm9ydGVkLCBvciB0aGUgcHJvamVjdCB3YXMgc3RvcHBlZCB0b28gc29v bi4gIFxuXG5EbyB5b3Ugd2FudCB0byBvcGVuIGl0IGZyb20gdGhlIHNlcnZlcj8nKSl3aW5k b3cubG9jYXRpb249J2h0dHA6Ly93d3cucy1oLXN5c3RlbXMuY28udWsvZ2hhbmEvYWNjcmEu aHRtbCciIHRwcGFicz0iaHR0cDovL3d3dy5zLWgtc3lzdGVtcy5jby51ay9naGFuYS9hY2Ny YS5odG1sIj48Qj5BY2NyYTwvQj48L0E+PEJSPjwvVEQ+PFREIFdJRFRIPSIyMCUiPjxBIEhS RUY9ImphdmFzY3JpcHQ6aWYoY29uZmlybSgnaHR0cDovL3d3dy5zLWgtc3lzdGVtcy5jby51 ay9naGFuYS9jYXBlLWNvYXN0Lmh0bWwgIFxuXG5UaGlzIGZpbGUgd2FzIG5vdCByZXRyaWV2 ZWQgYnkgVGVsZXBvcnQgUHJvLCBiZWNhdXNlIGl0IHdhcyB1bmF2YWlsYWJsZSwgb3IgaXRz IHJldHJpZXZhbCB3YXMgYWJvcnRlZCwgb3IgdGhlIHByb2plY3Qgd2FzIHN0b3BwZWQgdG9v IHNvb24uICBcblxuRG8geW91IHdhbnQgdG8gb3BlbiBpdCBmcm9tIHRoZSBzZXJ2ZXI/Jykp d2luZG93LmxvY2F0aW9uPSdodHRwOi8vd3d3LnMtaC1zeXN0ZW1zLmNvLnVrL2doYW5hL2Nh cGUtY29hc3QuaHRtbCciIHRwcGFicz0iaHR0cDovL3d3dy5zLWgtc3lzdGVtcy5jby51ay9n aGFuYS9jYXBlLWNvYXN0Lmh0bWwiPjxCPkNhcGUgQ29hc3Q8L0I+PC9BPjxCUj48L1REPjxU RCBXSURUSD0iMjAlIj48QSBIUkVGPSJqYXZhc2NyaXB0OmlmKGNvbmZpcm0oJ2h0dHA6Ly93 d3cucy1oLXN5c3RlbXMuY28udWsvZ2hhbmEva3VtYXNpLmh0bWwgIFxuXG5UaGlzIGZpbGUg d2FzIG5vdCByZXRyaWV2ZWQgYnkgVGVsZXBvcnQgUHJvLCBiZWNhdXNlIGl0IHdhcyB1bmF2 YWlsYWJsZSwgb3IgaXRzIHJldHJpZXZhbCB3YXMgYWJvcnRlZCwgb3IgdGhlIHByb2plY3Qg d2FzIHN0b3BwZWQgdG9vIHNvb24uICBcblxuRG8geW91IHdhbnQgdG8gb3BlbiBpdCBmcm9t IHRoZSBzZXJ2ZXI/Jykpd2luZG93LmxvY2F0aW9uPSdodHRwOi8vd3d3LnMtaC1zeXN0ZW1z LmNvLnVrL2doYW5hL2t1bWFzaS5odG1sJyIgdHBwYWJzPSJodHRwOi8vd3d3LnMtaC1zeXN0 ZW1zLmNvLnVrL2doYW5hL2t1bWFzaS5odG1sIj48Qj5LdW1hc2k8L0I+PC9BPjxCUj48L1RE PjxURCBXSURUSD0iMjAlIj48QSBIUkVGPSJqYXZhc2NyaXB0OmlmKGNvbmZpcm0oJ2h0dHA6 Ly93d3cucy1oLXN5c3RlbXMuY28udWsvZ2hhbmEvbW9sZS1uYXRpb25hbC1wYXJrLmh0bWwg IFxuXG5UaGlzIGZpbGUgd2FzIG5vdCByZXRyaWV2ZWQgYnkgVGVsZXBvcnQgUHJvLCBiZWNh dXNlIGl0IHdhcyB1bmF2YWlsYWJsZSwgb3IgaXRzIHJldHJpZXZhbCB3YXMgYWJvcnRlZCwg b3IgdGhlIHByb2plY3Qgd2FzIHN0b3BwZWQgdG9vIHNvb24uICBcblxuRG8geW91IHdhbnQg dG8gb3BlbiBpdCBmcm9tIHRoZSBzZXJ2ZXI/Jykpd2luZG93LmxvY2F0aW9uPSdodHRwOi8v d3d3LnMtaC1zeXN0ZW1zLmNvLnVrL2doYW5hL21vbGUtbmF0aW9uYWwtcGFyay5odG1sJyIg dHBwYWJzPSJodHRwOi8vd3d3LnMtaC1zeXN0ZW1zLmNvLnVrL2doYW5hL21vbGUtbmF0aW9u YWwtcGFyay5odG1sIj48Qj5Nb2xlIE5hdGlvbmFsIFBhcms8L0I+PC9BPjxCUj48L1REPjxU RCBXSURUSD0iMjAlIj48QSBIUkVGPSJqYXZhc2NyaXB0OmlmKGNvbmZpcm0oJ2h0dHA6Ly93 d3cucy1oLXN5c3RlbXMuY28udWsvZ2hhbmEvdGFrb3JhZGkuaHRtbCAgXG5cblRoaXMgZmls ZSB3YXMgbm90IHJldHJpZXZlZCBieSBUZWxlcG9ydCBQcm8sIGJlY2F1c2UgaXQgd2FzIHVu YXZhaWxhYmxlLCBvciBpdHMgcmV0cmlldmFsIHdhcyBhYm9ydGVkLCBvciB0aGUgcHJvamVj dCB3YXMgc3RvcHBlZCB0b28gc29vbi4gIFxuXG5EbyB5b3Ugd2FudCB0byBvcGVuIGl0IGZy b20gdGhlIHNlcnZlcj8nKSl3aW5kb3cubG9jYXRpb249J2h0dHA6Ly93d3cucy1oLXN5c3Rl bXMuY28udWsvZ2hhbmEvdGFrb3JhZGkuaHRtbCciIHRwcGFicz0iaHR0cDovL3d3dy5zLWgt c3lzdGVtcy5jby51ay9naGFuYS90YWtvcmFkaS5odG1sIj48Qj5UYWtvcmFkaTwvQj48L0E+ PEJSPjwvVEQ+PC9UUj48VFIgQUxJR049IkNFTlRFUiI+DQo8VEQgV0lEVEg9IjIwJSI+PEEg SFJFRj0iamF2YXNjcmlwdDppZihjb25maXJtKCdodHRwOi8vd3d3LnMtaC1zeXN0ZW1zLmNv LnVrL2doYW5hL3RhbWFsZS5odG1sICBcblxuVGhpcyBmaWxlIHdhcyBub3QgcmV0cmlldmVk IGJ5IFRlbGVwb3J0IFBybywgYmVjYXVzZSBpdCB3YXMgdW5hdmFpbGFibGUsIG9yIGl0cyBy ZXRyaWV2YWwgd2FzIGFib3J0ZWQsIG9yIHRoZSBwcm9qZWN0IHdhcyBzdG9wcGVkIHRvbyBz b29uLiAgXG5cbkRvIHlvdSB3YW50IHRvIG9wZW4gaXQgZnJvbSB0aGUgc2VydmVyPycpKXdp bmRvdy5sb2NhdGlvbj0naHR0cDovL3d3dy5zLWgtc3lzdGVtcy5jby51ay9naGFuYS90YW1h bGUuaHRtbCciIHRwcGFicz0iaHR0cDovL3d3dy5zLWgtc3lzdGVtcy5jby51ay9naGFuYS90 YW1hbGUuaHRtbCI+PEI+VGFtYWxlPC9CPjwvQT48QlI+PC9URD48VEQgV0lEVEg9IjIwJSI+ PEEgSFJFRj0iamF2YXNjcmlwdDppZihjb25maXJtKCdodHRwOi8vd3d3LnMtaC1zeXN0ZW1z LmNvLnVrL2doYW5hL3RlbWEuaHRtbCAgXG5cblRoaXMgZmlsZSB3YXMgbm90IHJldHJpZXZl ZCBieSBUZWxlcG9ydCBQcm8sIGJlY2F1c2UgaXQgd2FzIHVuYXZhaWxhYmxlLCBvciBpdHMg cmV0cmlldmFsIHdhcyBhYm9ydGVkLCBvciB0aGUgcHJvamVjdCB3YXMgc3RvcHBlZCB0b28g c29vbi4gIFxuXG5EbyB5b3Ugd2FudCB0byBvcGVuIGl0IGZyb20gdGhlIHNlcnZlcj8nKSl3 aW5kb3cubG9jYXRpb249J2h0dHA6Ly93d3cucy1oLXN5c3RlbXMuY28udWsvZ2hhbmEvdGVt YS5odG1sJyIgdHBwYWJzPSJodHRwOi8vd3d3LnMtaC1zeXN0ZW1zLmNvLnVrL2doYW5hL3Rl bWEuaHRtbCI+PEI+VGVtYTwvQj48L0E+PEJSPjwvVEQ+PFREPiZuYnNwOzwvVEQ+PFREPiZu YnNwOzwvVEQ+PFREPiZuYnNwOzwvVEQ+PC9UUj48L1RBQkxFPjxCUj4NCjxDRU5URVI+PFRB QkxFIEJPUkRFUj0iMSIgQk9SREVSQ09MT1I9IiMwMDAwNjYiPjxUUiBBTElHTj0iQ0VOVEVS Ij48VEQgQkdDT0xPUj0iI0ZGRkZGRiI+PEEgSFJFRj0iLi4vd29ybGQuaHRtbCIgdHBwYWJz PSJodHRwOi8vd3d3LnMtaC1zeXN0ZW1zLmNvLnVrL3dvcmxkLmh0bWwiPjxCPldvcmxkICZn dDs8L0I+PC9BPiA8QSBIUkVGPSIuLi9hZnJpY2EuaHRtbCIgdHBwYWJzPSJodHRwOi8vd3d3 LnMtaC1zeXN0ZW1zLmNvLnVrL2FmcmljYS5odG1sIj48Qj5BZnJpY2EgJmd0OzwvQj48L0E+ IDxCPkdoYW5hPC9CPjwvVEQ+PC9UUj48L1RBQkxFPjwvQ0VOVEVSPjxIUiBXSURUSD0iNzAl Ij48VEFCTEUgV0lEVEg9IjEwMCUiPjxUUiBBTElHTj0iQ0VOVEVSIj48VEQgV0lEVEg9IjE3 JSIgQUxJR049IkNFTlRFUiI+PFRBQkxFIFdJRFRIPSIxMDAlIiBCT1JERVI9IjEiIEJPUkRF UkNPTE9SPSIjMDAwMDY2Ij48VFI+PFREIEFMSUdOPSJDRU5URVIiIEJHQ09MT1I9IiNGRkZG RkYiPjxUQUJMRT48VFI+PFREIEFMSUdOPSJMRUZUIj48SU1HIFdJRFRIPSI3IiBIRUlHSFQ9 IjciIEFMVD0iIiBTUkM9Ii4uL2ltYWdlcy9ob3RlbC1idWxsZXQuZ2lmIiB0cHBhYnM9Imh0 dHA6Ly93d3cucy1oLXN5c3RlbXMuY28udWsvaW1hZ2VzL2hvdGVsLWJ1bGxldC5naWYiPjxB IEhSRUY9Ii4uL3VrLWNhci1yZW50YWwvaW5kZXguaHRtbCIgdHBwYWJzPSJodHRwOi8vd3d3 LnMtaC1zeXN0ZW1zLmNvLnVrL3VrLWNhci1yZW50YWwvaW5kZXguaHRtbCI+PEZPTlQgU0la RT0iLTEiPjxCPkNhciBSZW50YWw8L0I+PC9GT05UPjwvQT48QlI+PElNRyBXSURUSD0iNyIg SEVJR0hUPSI3IiBBTFQ9IiIgU1JDPSIuLi9pbWFnZXMvaG90ZWwtYnVsbGV0LmdpZiIgdHBw YWJzPSJodHRwOi8vd3d3LnMtaC1zeXN0ZW1zLmNvLnVrL2ltYWdlcy9ob3RlbC1idWxsZXQu Z2lmIj48QSBIUkVGPSIuLi93b3JsZC5odG1sIiB0cHBhYnM9Imh0dHA6Ly93d3cucy1oLXN5 c3RlbXMuY28udWsvd29ybGQuaHRtbCI+PEZPTlQgU0laRT0iLTEiPjxCPldvcmxkIFNlYXJj aDwvQj48L0ZPTlQ+PC9BPjxCUj48L1REPjwvVFI+PC9UQUJMRT48L1REPjwvVFI+PC9UQUJM RT48L1REPjxURCBXSURUSD0iNjYlIiBBTElHTj0iQ0VOVEVSIj48Y2VudGVyPjxpZnJhbWUg c3JjPSJqYXZhc2NyaXB0OmlmKGNvbmZpcm0oJ2h0dHA6Ly9sZWFkZXIubGlua2V4Y2hhbmdl LmNvbS80NTc5NzEvWDM4MTQ0Ny9zaG93aWZyYW1lPyAgXG5cblRoaXMgZmlsZSB3YXMgbm90 IHJldHJpZXZlZCBieSBUZWxlcG9ydCBQcm8sIGJlY2F1c2UgaXQgaXMgYWRkcmVzc2VkIG9u IGEgZG9tYWluIG9yIHBhdGggb3V0c2lkZSB0aGUgYm91bmRhcmllcyBzZXQgZm9yIGl0cyBT dGFydGluZyBBZGRyZXNzLiAgXG5cbkRvIHlvdSB3YW50IHRvIG9wZW4gaXQgZnJvbSB0aGUg c2VydmVyPycpKXdpbmRvdy5sb2NhdGlvbj0naHR0cDovL2xlYWRlci5saW5rZXhjaGFuZ2Uu Y29tLzQ1Nzk3MS9YMzgxNDQ3L3Nob3dpZnJhbWU/JyIgdHBwYWJzPSJodHRwOi8vbGVhZGVy LmxpbmtleGNoYW5nZS5jb20vNDU3OTcxL1gzODE0NDcvc2hvd2lmcmFtZT8iIHdpZHRoPTQ2 OCBoZWlnaHQ9NjAgbWFyZ2lud2lkdGg9MCBtYXJnaW5oZWlnaHQ9MCBoc3BhY2U9MCB2c3Bh Y2U9MCBmcmFtZWJvcmRlcj0wIHNjcm9sbGluZz1ubz48YSBocmVmPSJqYXZhc2NyaXB0Omlm KGNvbmZpcm0oJ2h0dHA6Ly9sZWFkZXIubGlua2V4Y2hhbmdlLmNvbS80NTc5NzEvWDM4MTQ0 Ny9jbGlja2xlICBcblxuVGhpcyBmaWxlIHdhcyBub3QgcmV0cmlldmVkIGJ5IFRlbGVwb3J0 IFBybywgYmVjYXVzZSBpdCBpcyBhZGRyZXNzZWQgb24gYSBkb21haW4gb3IgcGF0aCBvdXRz aWRlIHRoZSBib3VuZGFyaWVzIHNldCBmb3IgaXRzIFN0YXJ0aW5nIEFkZHJlc3MuICBcblxu RG8geW91IHdhbnQgdG8gb3BlbiBpdCBmcm9tIHRoZSBzZXJ2ZXI/Jykpd2luZG93LmxvY2F0 aW9uPSdodHRwOi8vbGVhZGVyLmxpbmtleGNoYW5nZS5jb20vNDU3OTcxL1gzODE0NDcvY2xp Y2tsZSciIHRwcGFicz0iaHR0cDovL2xlYWRlci5saW5rZXhjaGFuZ2UuY29tLzQ1Nzk3MS9Y MzgxNDQ3L2NsaWNrbGUiIHRhcmdldD0iX3RvcCI+PGltZyB3aWR0aD00NjggaGVpZ2h0PTYw IGJvcmRlcj0wIGlzbWFwIGFsdD0iQmFubmVyIGFkdmVydCIgc3JjPSIuLi8uLi9pbWFnZS5s aW5rZXhjaGFuZ2UuY29tLzAxLzY1LzYyLzYzL2Jhbm5lcjQ2OHg2MC5naWYiIHRwcGFicz0i aHR0cDovL2xlYWRlci5saW5rZXhjaGFuZ2UuY29tLzQ1Nzk3MS9YNjY2NjE2L3Nob3dsZT8i PjwvYT48L2lmcmFtZT48YnI+PGEgaHJlZj0iamF2YXNjcmlwdDppZihjb25maXJtKCdodHRw Oi8vbGVhZGVyLmxpbmtleGNoYW5nZS5jb20vNDU3OTcxL1g2NjY2MTYvY2xpY2tsb2dvICBc blxuVGhpcyBmaWxlIHdhcyBub3QgcmV0cmlldmVkIGJ5IFRlbGVwb3J0IFBybywgYmVjYXVz ZSBpdCBpcyBhZGRyZXNzZWQgb24gYSBkb21haW4gb3IgcGF0aCBvdXRzaWRlIHRoZSBib3Vu ZGFyaWVzIHNldCBmb3IgaXRzIFN0YXJ0aW5nIEFkZHJlc3MuICBcblxuRG8geW91IHdhbnQg dG8gb3BlbiBpdCBmcm9tIHRoZSBzZXJ2ZXI/Jykpd2luZG93LmxvY2F0aW9uPSdodHRwOi8v bGVhZGVyLmxpbmtleGNoYW5nZS5jb20vNDU3OTcxL1g2NjY2MTYvY2xpY2tsb2dvJyIgdHBw YWJzPSJodHRwOi8vbGVhZGVyLmxpbmtleGNoYW5nZS5jb20vNDU3OTcxL1g2NjY2MTYvY2xp Y2tsb2dvIiB0YXJnZXQ9Il90b3AiPjxpbWcgc3JjPSIuLi8uLi9pbWFnZS5saW5rZXhjaGFu Z2UuY29tL2xlbG9nby5naWYiIHRwcGFicz0iaHR0cDovL2xlYWRlci5saW5rZXhjaGFuZ2Uu Y29tLzQ1Nzk3MS9YNjY2NjE2L3Nob3dsb2dvPyIgd2lkdGg9NDY4IGhlaWdodD0xNiBib3Jk ZXI9MCBpc21hcCBhbHQ9IkJhbm5lciBhZHZlcnQiPjwvYT48YnI+PC9jZW50ZXI+PC9URD48 VEQgV0lEVEg9IjE3JSI+PFRBQkxFIFdJRFRIPSIxMDAlIiBCT1JERVI9IjEiIEJPUkRFUkNP TE9SPSIjMDAwMDY2Ij48VFI+PFREIEFMSUdOPSJDRU5URVIiIEJHQ09MT1I9IiNGRkZGRkYi PjxUQUJMRT48VFI+PFREIEFMSUdOPSJMRUZUIj48SU1HIFdJRFRIPSI3IiBIRUlHSFQ9Ijci IEFMVD0iIiBTUkM9Ii4uL2ltYWdlcy9ob3RlbC1idWxsZXQuZ2lmIiB0cHBhYnM9Imh0dHA6 Ly93d3cucy1oLXN5c3RlbXMuY28udWsvaW1hZ2VzL2hvdGVsLWJ1bGxldC5naWYiPjxhIGhy ZWY9Ii4uL2ZyaWVuZC5odG1sIiB0cHBhYnM9Imh0dHA6Ly93d3cucy1oLXN5c3RlbXMuY28u dWsvZnJpZW5kLmh0bWwiIG9uY2xpY2s9IndpbmRvdy5vcGVuKCdyZWZlci5odG1sJywnYXJv bVduZCcsJ3dpZHRoPTUzNSxoZWlnaHQ9MjMwLHNjcm9sbGJhcnM9eWVzLG1lbnViYXI9bm8s cmVzaXphYmxlPXllcycpOyByZXR1cm4gZmFsc2U7IiB0YXJnZXQ9InJlZmVyIj48Rk9OVCBT SVpFPSItMSI+PEI+VGVsbCBhIEZyaWVuZDwvQj48L0ZPTlQ+PC9BPjxCUj48SU1HIFdJRFRI PSI3IiBIRUlHSFQ9IjciIEFMVD0iIiBTUkM9Ii4uL2ltYWdlcy9ob3RlbC1idWxsZXQuZ2lm IiB0cHBhYnM9Imh0dHA6Ly93d3cucy1oLXN5c3RlbXMuY28udWsvaW1hZ2VzL2hvdGVsLWJ1 bGxldC5naWYiPjxBIEhSRUY9Ii4uL2NvbnZlcnQuaHRtbCIgdHBwYWJzPSJodHRwOi8vd3d3 LnMtaC1zeXN0ZW1zLmNvLnVrL2NvbnZlcnQuaHRtbCI+PEZPTlQgU0laRT0iLTEiPjxCPkV4 Y2hhbmdlIFJhdGVzPC9CPjwvRk9OVD48L0E+PEJSPjwvVEQ+PC9UUj48L1RBQkxFPjwvVEQ+ PC9UUj48L1RBQkxFPjwvVEQ+PC9UUj48L1RBQkxFPjxDRU5URVI+PEFERFJFU1M+U21vb3Ro IEhvdW5kIFN5c3RlbXM8QlI+UCBPIEJveCAzNDM8QlI+Q2hlbHRlbmhhbTxCUj5HTDUwIDNZ WDxCUj5Vbml0ZWQgS2luZ2RvbSBUZWxlcGhvbmU6ICs0NCAoMCkxMjQyIDUyOTUwOTxCUj5G YXg6ICs0NCAoMCkxMjQyIDIyODQwMTxCUj48Qj5FLU1haWw6PC9CPjxBIEhSRUY9ImphdmFz Y3JpcHQ6aWYoY29uZmlybSgnaHR0cDovL3d3dy5zbW9vdGhob3VuZC5jby51ay9jb250YWN0 Lmh0bWwgIFxuXG5UaGlzIGZpbGUgd2FzIG5vdCByZXRyaWV2ZWQgYnkgVGVsZXBvcnQgUHJv LCBiZWNhdXNlIGl0IGlzIGFkZHJlc3NlZCBvbiBhIGRvbWFpbiBvciBwYXRoIG91dHNpZGUg dGhlIGJvdW5kYXJpZXMgc2V0IGZvciBpdHMgU3RhcnRpbmcgQWRkcmVzcy4gIFxuXG5EbyB5 b3Ugd2FudCB0byBvcGVuIGl0IGZyb20gdGhlIHNlcnZlcj8nKSl3aW5kb3cubG9jYXRpb249 J2h0dHA6Ly93d3cuc21vb3RoaG91bmQuY28udWsvY29udGFjdC5odG1sJyIgdHBwYWJzPSJo dHRwOi8vd3d3LnNtb290aGhvdW5kLmNvLnVrL2NvbnRhY3QuaHRtbCI+IGluZm9ybWF0aW9u QHNtb290aGhvdW5kLmNvbTwvQT4NCjwvQUREUkVTUz48L0NFTlRFUj48UCBBTElHTj1DRU5U RVI+Q29weXJpZ2h0ICZjb3B5OyAxOTk3IHRvIDIwMDIsIFNtb290aCBIb3VuZCBTeXN0ZW1z PEJSPjxQIEFMSUdOPUNFTlRFUj48Rk9OVCBTSVpFPS0xPkFsbCBwcmljZXMgYXJlIGFwcHJv eGltYXRlIGFuZCBtYXkgdmFyeSBieSB0aW1lIG9mIHllYXIgYW5kIGRheSBvZiB3ZWVrLiBQ bGVhc2UgY2hlY2sgd2l0aCB0aGUgaG90ZWwgZm9yIGV4YWN0IHByaWNlcyBmb3IgeW91ciBz dGF5LjwvRk9OVD48L1A+PFAgQUxJR049Q0VOVEVSPjxBIEhSRUY9ImphdmFzY3JpcHQ6aWYo Y29uZmlybSgnaHR0cDovL3d3dy5zbW9vdGhob3VuZC5jby51ay9wcml2YWN5Lmh0bWwgIFxu XG5UaGlzIGZpbGUgd2FzIG5vdCByZXRyaWV2ZWQgYnkgVGVsZXBvcnQgUHJvLCBiZWNhdXNl IGl0IGlzIGFkZHJlc3NlZCBvbiBhIGRvbWFpbiBvciBwYXRoIG91dHNpZGUgdGhlIGJvdW5k YXJpZXMgc2V0IGZvciBpdHMgU3RhcnRpbmcgQWRkcmVzcy4gIFxuXG5EbyB5b3Ugd2FudCB0 byBvcGVuIGl0IGZyb20gdGhlIHNlcnZlcj8nKSl3aW5kb3cubG9jYXRpb249J2h0dHA6Ly93 d3cuc21vb3RoaG91bmQuY28udWsvcHJpdmFjeS5odG1sJyIgdHBwYWJzPSJodHRwOi8vd3d3 LnNtb290aGhvdW5kLmNvLnVrL3ByaXZhY3kuaHRtbCI+PEZPTlQgU0laRT0tMT5Qcml2YWN5 IFBvbGljeTwvRk9OVD48L0E+DQo8L1A+PC9CT0RZPjwvSFRNTD=9 --U06S5E84jf27z9G2V33j7pg4iQ-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 08:20: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 IAA21912 for ; Thu, 7 Nov 2002 08:20:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7DM9M16750 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 08:22:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7DM7v16739; Thu, 7 Nov 2002 08:22: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 gA7DM0v16703 for ; Thu, 7 Nov 2002 08:22:00 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21788 for ; Thu, 7 Nov 2002 08:19:26 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id gA7DLsg18224; Thu, 7 Nov 2002 14:21:55 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail3.siemens.de (8.11.6/8.11.6) with SMTP id gA7DLsQ19264; Thu, 7 Nov 2002 14:21:54 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Geib, Ruediger" , Cc: Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation identifier Date: Thu, 7 Nov 2002 14:23:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi ruediger! see my comments inline: > > Hi Marcus, > > > And the number space for the reservation id could be 5-dimensionl > > containing src/dest addr, ports, and proto number... > > Yes, that's kind of the largest possible reservation ID. that's probably a bad choice since it changes due to - movement - ipsec encryption - other tunneling techniques - ipv4/ipv6 transition etc. > > > but it can also be derived from any other information > > or chosen randomly etc. > > I disagree. The reservation ID must be non ambiguous. A part > of it may be assigned randomly. A simple solution may be > reservation ID = source address + random number. which source address? home address / care-of address if home address then what happens without mobility. if care-of address then there is a mobility problem. both? ciao hannes > > Regards, Rüdiger > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 08:41: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 IAA23619 for ; Thu, 7 Nov 2002 08:41:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7DhIC18209 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 08:43: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 gA7DhEv18184; Thu, 7 Nov 2002 08:43: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 gA7Dg2v18118 for ; Thu, 7 Nov 2002 08:42:02 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23482 for ; Thu, 7 Nov 2002 08:39:29 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gA7Dfxw00536; Thu, 7 Nov 2002 14:41:59 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail3.siemens.de (8.11.6/8.11.6) with SMTP id gA7DfwQ03688; Thu, 7 Nov 2002 14:41:59 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Melinda Shore" Cc: "Bob Braden" , Subject: RE: [NSIS] Key management Date: Thu, 7 Nov 2002 14:43:10 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200211061517.AAR69881@mira-sjc5-4.cisco.com> Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi melinda! please see my comments inline: > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, November 06, 2002 4:22 PM > To: Hannes.Tschofenig@siemens.com > Cc: Bob Braden; nsis@ietf.org > Subject: Re: [NSIS] Key management > > > > i agree with you that the key management should be > > addressed. the question where the keys come from is > > independent from integrity or confidentiality protection. > > Unfortunately it's not completely independent. For example > the reasonable choices for IPSec are IKE, pre-shared keys > (which is probably a bad choice for us), or KINK, while for > TLS it's PKI. For us the choice of a keying mechanism is > going to come down to some combination of 1) what security > protocols we use, 2) what our understanding of the > relationships among the entities is going to be (i.e. if > there's just a few PSKs might be fine, if they're all in the > same domain KINK might be fine, etc.), and so on. i see your arguments. it is true that in real world protocols you are with some choices somehow limited in the number of ciphersuites, integrity algorithms. (an example: if you want to use a special encryption algorithm - for example camilla - then you might limit your scope of protocols. but i am not quite sure that one would like to place such contraints.) the issue i wanted to raise is that key management still has to be discussed differently to the type of protection later offered. some examples: authentication and key exchange protocols for ipsec are: ike, soi (in the near future) and kink (and others). they all offer ipsec sas which support algorithms for confidentiality protection and algorithms for integrity protection tls has its key management built-in. there are however extensions such that srp, kerberos or public key based techniques can be used. still the algorithms tls offers algorithms for confidentiality protection and for integrity protection. if you create your own authentication and key exchange protocol (and a seperate protocol for sa parameter negotiation) you might want to limit it only to confidentiality protection. but you might want to have a particular reason for that. > > I think that at this point the most helpful thing would be > to identify the elements that we'd use as the basis for a > later decision about keying. i think that the basis for a authentication and key exchange protocol selection should be the trust relationships and the architectural assumptions. you mention that ike with pre-shared secrets might not be the right choice. this would be such an architectural assumption. these type of trust relationships and assumptions need a careful investigation (e.g. based on scenarios). ciao hannes > > Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 08:41: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 IAA23623 for ; Thu, 7 Nov 2002 08:41:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7DhJq18222 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 08:43:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7DhFv18199; Thu, 7 Nov 2002 08:43: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 gA7DgFv18123 for ; Thu, 7 Nov 2002 08:42:15 -0500 Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23498 for ; Thu, 7 Nov 2002 08:39:42 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA09051 for ; Thu, 7 Nov 2002 14:42:10 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA05593 for ; Thu, 7 Nov 2002 14:42:11 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2656.59) id ; Thu, 7 Nov 2002 14:41:37 +0100 Message-ID: <69EB30B981C8D511AC370002A55CBE27017D415C@MCHH2A4E> From: ICN Genesis Mose To: "'nsis@ietf.org'" Cc: "'Heinrich.Hussmann@inf.tu-dresden.de'" Date: Thu, 7 Nov 2002 14:41:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Subject: [NSIS] Comment : RSVP Analysis Draft Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hello Everyone, I am currently doing my Master Thesis at Siemens AG, Munich under Dresden University of Technology and work focus is QoS on access networks which is related to the EU project AQUILA (http://www.ist-aquila.org/). The thesis also comes up with a comparison between RSVP, YESSIR and Boomerang in access network scenarios and in my study I have come to the conclusion that RSVP in spite of its complex architecture can still be efficiently used in Access and some other architecture in the core network, like AQUILA. Though YESSIR presents a more efficient alternative to RSVP, but due to it being signaled over RTP, only multimedia traffic can be guaranteed QoS, and if traffic independent QoS is required then it does not serve the purpose. Though Boomerang offers a very efficient architecture but the wide support of RSVP on routers and OS plays towards its favor. The major complexity of RSVP starts in the core where the number of flows increases drastically, but in access where the flows are limited, it can efficiently be used. In the work I make relevant changes to terminate RSVP in the ingress access and start a AQUILA session on the edge router for core and then re-start RSVP on egress to complete edge to edge QoS. In further work I would try to prove that this solution is better than pure RSVP solution. I think the work might be of interest to NSIS for further discussion. Regards, Sandeep Misra. ------------------------------------------------------------------------- Sandeep Misra ICN WN CC NA A19 Siemens AG Hofmannstr. 51, D-81379 Munich. Tel(O) : +49 89 72258443 Project AQUILA : http://www.ist-aquila.org Core Team Member - Siemens InterGreat : http://intranet.icn.siemens.de/intergreat -------------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 08:51: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 IAA24145 for ; Thu, 7 Nov 2002 08:51:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7Dr7v18671 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 08:53: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 gA7Dr4v18656; Thu, 7 Nov 2002 08:53: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 gA7Dq6v18607 for ; Thu, 7 Nov 2002 08:52:06 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24047 for ; Thu, 7 Nov 2002 08:49:33 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id gA7Dq1g12213; Thu, 7 Nov 2002 14:52:01 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail3.siemens.de (8.11.6/8.11.6) with SMTP id gA7Dq0Q11468; Thu, 7 Nov 2002 14:52:00 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Melinda Shore" , "Geib, Ruediger" Cc: Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Date: Thu, 7 Nov 2002 14:53:12 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200211061525.AAR70053@mira-sjc5-4.cisco.com> Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi melinda, hi ruediger! > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, November 06, 2002 4:30 PM > To: Geib, Ruediger > Cc: Hannes.Tschofenig@siemens.com; nsis@ietf.org > Subject: Re: [NSIS] Req-Draft: Open Issue 4: Confidentiality of > signaling messages > > > > To me, a simple relay doesn't have to operate encryption. > > The correct answer to any technical question is "it > depends," and I think it this case it comes down to > depending on how the application layer is split from the > transport layer, what information is contained in the > transport layer, and if the information that a relay would > need to forward the message correctly is itself encrypted. basically we can not give a concrete answer to it. if you can clearly specify what the function of a relay is then it might be easier to give an answer for it. for example: if the only purpose of the relay is to forward the message without processing nsis specific parts then there is no reason to have this entity as a nsis node. if the relay might even modify the message then there is no reason why not to treat it as a regular nsis entity. > > My suspicion is that the information one might want to > protect from prying eyes will tend to be carried in the > application, and that any information that could be derived > from looking at transport layer daya could also be derived > from traffic analysis. if someone want to apply security only at the application layer then - you might restrict yourself to a limited number of security mechanisms (cms would be a good choice) - you will not receive protection for the transport relevant parts. btw: ipsec even protects the transport layer vs. tls provides protection above the transport layer (i.e. it does not protect the transport layer header fields). instead of discussing security at the transport or the application layer it would suggest to consider the question of peer-to-peer vs. non peer-to-peer protection first. if people think that there is need for non peer-to-peer protection then some type of "application layer" security mechanisms have to be introduced anyway. ciao hannes > > Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 09:20: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 JAA25390 for ; Thu, 7 Nov 2002 09:20:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7EMEf20378 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 09:22: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 gA7EMBv20371; Thu, 7 Nov 2002 09:22: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 gA7EJOv20212 for ; Thu, 7 Nov 2002 09:19:24 -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 JAA25329 for ; Thu, 7 Nov 2002 09:16: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-4.cisco.com (8.12.2/8.12.2) with ESMTP id gA7EJLot016141; Thu, 7 Nov 2002 06:19:21 -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 AAS11264; Thu, 7 Nov 2002 06:14:36 -0800 (PST) Message-Id: <200211071414.AAS11264@mira-sjc5-4.cisco.com> To: Hannes.Tschofenig@siemens.com cc: "Bob Braden" , nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Key management In-Reply-To: Message from "Hannes Tschofenig" of "Thu, 07 Nov 2002 14:43:10 +0100." Date: Thu, 07 Nov 2002 09:19:19 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > the issue i wanted to raise is that key management still has to be discussed > differently to the type of protection later offered. Absolutely, and this is where many other IETF documents leave something (ahem) to be desired. But still, you can't talk about key management completely independently of the security protocol. As I said, I think for the purposes of requirements and framework it is probably best to identify what the context and broad criteria for the decision will be. For example, issues like the ability to operate across domains come into play. This is where your threat analysis document becomes very useful. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 10:08: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 KAA27228 for ; Thu, 7 Nov 2002 10:08:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7FAeV24032 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 10:10: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 gA7FAbv23988; Thu, 7 Nov 2002 10:10: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 gA7Exfv22859 for ; Thu, 7 Nov 2002 09:59:41 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26726 for ; Thu, 7 Nov 2002 09:57:09 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gA7Exaw26969; Thu, 7 Nov 2002 15:59:36 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail3.siemens.de (8.11.6/8.11.6) with SMTP id gA7ExaQ02538; Thu, 7 Nov 2002 15:59:36 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Melinda Shore" Cc: "Bob Braden" , Subject: RE: [NSIS] Key management Date: Thu, 7 Nov 2002 16:00:47 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200211071414.AAS11264@mira-sjc5-4.cisco.com> Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi melinda! i agree with you that key managment is a very important issue for nsis. as you mentioned there are some areas which deserve particular attention when it comes to deployment issues. especially the area of inter-domain and the first-peer communication is difficult. for intra-domain there is a large degree of freedom for a network operator to chose whatever mechanism and key management infrastructure is best suitable. considering the large number of scenarios and applications where nsis should/could be used it is difficult to specify exact requirements. proposing only a single mechanism might be good in some environments but might not fit for others. hence my personal opinion is to use some ietf standardised mechanisms which give some degree of freedom. ipsec is an example of such a protocol. it only worries about protection of data traffic. it gives a network architect (or network operator) the possiblity to either choose between ike (and the different authentication mechanisms), son-of-ike and kink (kerberos based). packetcable peoplemight for example want to use ipsec (and kink as key management protocol) to protect nsis signaling messages whereas telecom people might not want to use kerberos to authenticate their users. ciao hannes > > > the issue i wanted to raise is that key management still has to > be discussed > > differently to the type of protection later offered. > > Absolutely, and this is where many other IETF documents > leave something (ahem) to be desired. But still, you can't > talk about key management completely independently of the > security protocol. As I said, I think for the purposes of > requirements and framework it is probably best to identify > what the context and broad criteria for the decision will > be. For example, issues like the ability to operate across > domains come into play. This is where your threat analysis > document becomes very useful. > > Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 10:11: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 KAA27382 for ; Thu, 7 Nov 2002 10:11:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7FD8i24286 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 10:13: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 gA7FD4v24267; Thu, 7 Nov 2002 10: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 gA7FCrv24229 for ; Thu, 7 Nov 2002 10:12:53 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27352 for ; Thu, 7 Nov 2002 10:10:21 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 7 Nov 2002 15:25:07 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Nov 2002 15:25:06 +0100 Message-Id: From: "Geib, Ruediger" To: Hannes.Tschofenig@siemens.com Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Thu, 7 Nov 2002 15:25:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA7FCrv24230 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello Hannes, my comments in line >>> Marcus: >>> And the number space for the reservation id could be 5-dimensionl >>> containing src/dest addr, ports, and proto number... >> Rüdiger: >> Yes, that's kind of the largest possible reservation ID. > Hannes: > that's probably a bad choice since it changes due to > - movement > - ipsec encryption > - other tunneling techniques > - ipv4/ipv6 transition > etc. Rüdiger: In general, I'd regard the so called "flow identifier" as the largest possible reservation ID, no matter how it looks like. >>> Marcus: >>> but it can also be derived from any other information >>> or chosen randomly etc. >> Rüdiger: >> I disagree. The reservation ID must be non ambiguous. A part >> of it may be assigned randomly. A simple solution may be >> reservation ID = source address + random number. > Hannes: > which source address? home address / care-of address > if home address then what happens without mobility. > if care-of address then there is a mobility problem. > both? I think the care-of address will do. As I've explained in another message, I'd expect signaling with complete flow ID should the latter change. That will solve the mobility problem. The above is valid for sender based reservations. Things may look different for receiver based schemes like RSVP in combination with mobility. I'm not deeply into mobility. The flow towards a mobile terminal once was routed to the home address and from there to the care-of address. If it is still like that, our signaling protocol must care about the issue. Wouldn't a reservation ID be helpful then? Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 10:24: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 KAA27950 for ; Thu, 7 Nov 2002 10:24:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7FQBB25019 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 10:26: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 gA7FQ8v25012; Thu, 7 Nov 2002 10:26: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 gA7FOFv24914 for ; Thu, 7 Nov 2002 10:24:15 -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 KAA27797 for ; Thu, 7 Nov 2002 10:21:42 -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 gA7FOBPP017927; Thu, 7 Nov 2002 07:24:11 -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 AAS12675; Thu, 7 Nov 2002 07:19:26 -0800 (PST) Message-Id: <200211071519.AAS12675@mira-sjc5-4.cisco.com> To: Hannes.Tschofenig@siemens.com cc: "Bob Braden" , nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Key management In-Reply-To: Message from "Hannes Tschofenig" of "Thu, 07 Nov 2002 16:00:47 +0100." Date: Thu, 07 Nov 2002 10:24:09 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > considering the large number of scenarios and applications where nsis > should/could be used it is difficult to specify exact requirements. > proposing only a single mechanism might be good in some environments but > might not fit for others. hence my personal opinion is to use some ietf > standardised mechanisms which give some degree of freedom. While I agree with both points I don't think that one follows from the other. Again, I think that we need to lay out the context and trade-offs. We know from experience that "just use IPSec" isn't going to lead to interoperable, secure, implementable specifications. The decisions that are ultimately made about key management will hinge on 1) the specific keying problems we're trying to solve, and 2) the security protocol(s) this is/are selected to protect both the transport layer and the application. BTW, we should think about the performance implications of doing a key exchange in the transport layer + a key exchange in the application layer. It may be desirable (more efficient) to use a secure channel established in the transport layer to do keying for the application, and that has implications for how the transport is secured (i.e. it relies on confidentiality protection). Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 11:11: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 LAA00223 for ; Thu, 7 Nov 2002 11:11:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7GDIA28537 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 11:13: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 gA7GDFv28530; Thu, 7 Nov 2002 11:13: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 gA7GCov28461 for ; Thu, 7 Nov 2002 11:12:50 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00122 for ; Thu, 7 Nov 2002 11:10:17 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gA7GCjw11487; Thu, 7 Nov 2002 17:12:45 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail3.siemens.de (8.11.6/8.11.6) with SMTP id gA7GCjQ20817; Thu, 7 Nov 2002 17:12:45 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Melinda Shore" Cc: "Bob Braden" , Subject: RE: [NSIS] Key management Date: Thu, 7 Nov 2002 17:13:56 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200211071519.AAS12675@mira-sjc5-4.cisco.com> Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi melinda! please find my comments inline: > > considering the large number of scenarios and applications where nsis > > should/could be used it is difficult to specify exact requirements. > > proposing only a single mechanism might be good in some environments but > > might not fit for others. hence my personal opinion is to use some ietf > > standardised mechanisms which give some degree of freedom. > > While I agree with both points I don't think that one > follows from the other. Again, I think that we need to lay > out the context and trade-offs. We know from experience > that "just use IPSec" isn't going to lead to interoperable, > secure, implementable specifications. i agree with you that it is not just that simple. i, however, favor an approach where standard mechanisms are used as far as possible. this saves both work and mistakes. > The decisions that > are ultimately made about key management will hinge on 1) > the specific keying problems we're trying to solve, what do you mean by keying problem. do you refer to symmetric vs. asymmetric cryptography? > and 2) > the security protocol(s) this is/are selected to protect > both the transport layer and the application. true. i can agree to that. > > BTW, we should think about the performance implications of > doing a key exchange in the transport layer + a key exchange > in the application layer. we should always keep performance in mind. hence i argue that it might not the most performance efficient approach to have security at both layers if they terminate at the same endpoints. we should, however, have no illusion about the fact that an authentication and key exchange is associated with some cost. keys and security associations do not appear by magic. related to performance i would also like to point a typical approach in this area (and other area as well): to establishment a security association which can then be used to protect signaling messages (or parts of it) the benefit of this approach is that an authentication and key establishment is done once. protection of a possibly large number of signaling message can then done by very efficient means. > It may be desirable (more > efficient) to use a secure channel established in the > transport layer to do keying for the application, and that > has implications for how the transport is secured (i.e. it > relies on confidentiality protection). what do you mean by keying for the application based on the secure channel? ciao hannes > > Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 11:28: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 LAA00927 for ; Thu, 7 Nov 2002 11:28:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7GULw29370 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 11:30:21 -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 gA7GUJv29359; Thu, 7 Nov 2002 11:30: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 gA7GRnv29201 for ; Thu, 7 Nov 2002 11:27:49 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00819 for ; Thu, 7 Nov 2002 11:25:16 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA7GRiQ1006937; Thu, 7 Nov 2002 17:27:44 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WJS4R240; Thu, 7 Nov 2002 17:27:44 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Nov 2002 17:28:14 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C022BCE1@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 994f4ff8 ca231590 8c40f696 00000138 From: "Vlora Rexhepi (ELN)" To: "'john.loughney@nokia.com'" Cc: nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt Date: Thu, 7 Nov 2002 17:28:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi John, Is this draft really an NSIS WG draft or is it just the name that is misleading? Regards, Vlora |-----Original Message----- |From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] |Sent: Friday, November 01, 2002 2:43 PM |Cc: nsis@ietf.org |Subject: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt | | |A New Internet-Draft is available from the on-line |Internet-Drafts directories. |This draft is a work item of the Next Steps in Signaling |Working Group of the IETF. | | Title : Analysis of Existing Quality of |Service Signaling | Protocols | Author(s) : J. Manner, X. Fu | Filename : draft-ietf-nsis-signalling-analysis-00.txt | Pages : 22 | Date : 2002-10-31 | |This document presents a review of existing protocols for signalling |the Quality of Service requirements of flows to nodes in an IP |network. Protocols are reviewed independently and not compared |against the NSIS requirements document nor to RSVP itself. The |purpose is to learn from existing work and to avoid common |misconceptions about the protocols. A further goal is to avoid to |redesign ideas already implemented in another protocol. | |A URL for this Internet-Draft is: |http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling- |analysis-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-nsis-signalling-analysis-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-nsis-signalling-analysis-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. | _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 11:32: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 LAA01209 for ; Thu, 7 Nov 2002 11:32:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7GY4d29638 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 11:34: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 gA7GY2v29579; Thu, 7 Nov 2002 11:34: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 gA7GX4v29490 for ; Thu, 7 Nov 2002 11:33:04 -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 LAA01069 for ; Thu, 7 Nov 2002 11:30:27 -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 gA7GWhxF004464; Thu, 7 Nov 2002 08:32:43 -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 AAS15002; Thu, 7 Nov 2002 08:28:06 -0800 (PST) Message-Id: <200211071628.AAS15002@mira-sjc5-4.cisco.com> To: Hannes.Tschofenig@siemens.com cc: "Bob Braden" , nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Key management In-Reply-To: Message from "Hannes Tschofenig" of "Thu, 07 Nov 2002 17:13:56 +0100." Date: Thu, 07 Nov 2002 11:32:48 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > i agree with you that it is not just that simple. i, however, favor an > approach where standard mechanisms are used as far as possible. this saves > both work and mistakes. There's no disagreement here, other than that I think that the options may be more constrained than you're suggesting. > what do you mean by keying problem. do you refer to > symmetric vs. asymmetric cryptography? No, higher level than that (transforms are mechanism, and we don't specify mechanism quite yet). The problems may be things like establishing secure channels between entities that don't have pre-existing relationships, or keying across a potentially hostile network. > we should always keep performance in mind. hence i argue that it might not > the most performance efficient approach to have security at both layers if > they terminate at the same endpoints. I think we're arguing the same thing, but it still comes back to decisions that are made in the framework. For example, if the transport layer is keying hop-by-hop but you want NSIS applications (say, NAT communication) to be able to do bidirectional authentication, you face the problem of getting keys between the NAT, which may be more than one hop away from the NSIS initiator, and the NSIS initiator itself. > we should, however, have no illusion about the fact that an authentication > and key exchange is associated with some cost. keys and security > associations do not appear by magic. Of course, but you still need to do the right thing. Pre-shared keys makes keying cheap but it has other attributes that might make it unattractive for some scenarios. What are the tradeoffs? > what do you mean by keying for the application based on the secure channel? What you described above - establishing a secure channel at the transport layer and letting the application use it to exchange keys. But as I've said there may be application considerations that come into play, like the problem of authenticating devices multiple hops away. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 11: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 LAA01487 for ; Thu, 7 Nov 2002 11:47:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7Gn8t30878 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 11:49: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 gA7Gn6v30865; Thu, 7 Nov 2002 11:49:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7Gh2v30615 for ; Thu, 7 Nov 2002 11:43:02 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01346 for ; Thu, 7 Nov 2002 11:40:28 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id gA7Ggvn07283; Thu, 7 Nov 2002 17:42:57 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail3.siemens.de (8.11.6/8.11.6) with SMTP id gA7GgvQ06234; Thu, 7 Nov 2002 17:42:57 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Geib, Ruediger" Cc: Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation identifier Date: Thu, 7 Nov 2002 17:44:07 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi ruediger! see my comments inline [hannes]: > Hello Hannes, > > my comments in line > > >>> Marcus: > >>> And the number space for the reservation id could be 5-dimensionl > >>> containing src/dest addr, ports, and proto number... > > >> Rüdiger: > >> Yes, that's kind of the largest possible reservation ID. > > > Hannes: > > that's probably a bad choice since it changes due to > > - movement > > - ipsec encryption > > - other tunneling techniques > > - ipv4/ipv6 transition > > etc. > > Rüdiger: > In general, I'd regard the so called "flow identifier" as the > largest possible reservation ID, no matter how it looks like. [hannes] my point of view is that the reservation (or session) identifier should be something different than the flow identifier. if this is not the case then no such separation is required. > > >>> Marcus: > >>> but it can also be derived from any other information > >>> or chosen randomly etc. > > >> Rüdiger: > >> I disagree. The reservation ID must be non ambiguous. A part > >> of it may be assigned randomly. A simple solution may be > >> reservation ID = source address + random number. > > > Hannes: > > which source address? home address / care-of address > > if home address then what happens without mobility. > > if care-of address then there is a mobility problem. > > both? > > I think the care-of address will do. As I've explained > in another message, I'd expect signaling with complete > flow ID should the latter change. That will solve the > mobility problem. [hannes] i am not sure to which mail you are referring. in any case i have the strong feeling that you need to have some sort of session / reservation identifier which is not subject to change. if you also want to change this identifier then you need to update it along the entire path. maybe i do not catch your point. > > The above is valid for sender based reservations. Things > may look different for receiver based schemes like RSVP > in combination with mobility. [hannes] are you sure? both sender and receive can move. i guess that there is still a need for analysis work. > > I'm not deeply into mobility. The flow towards a mobile > terminal once was routed to the home address and from > there to the care-of address. If it is still like that, > our signaling protocol must care about the issue. > Wouldn't a reservation ID be helpful then? [hannes] doesn't this contradict to your previous argument? ciao hannes > > Regards, Rüdiger > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 13:30: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 NAA05397 for ; Thu, 7 Nov 2002 13:30:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7IWEE05354 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 13:32: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 gA7IWCv05347; Thu, 7 Nov 2002 13:32: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 gA7IV8v05318 for ; Thu, 7 Nov 2002 13:31:08 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05360 for ; Thu, 7 Nov 2002 13:28:34 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA7IV3a14333; Thu, 7 Nov 2002 10:31:03 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id SAA05620; Thu, 7 Nov 2002 18:31:02 GMT Date: Thu, 7 Nov 2002 18:31:02 GMT Message-Id: <200211071831.SAA05620@gra.isi.edu> To: nsis@ietf.org Cc: braden@ISI.EDU, lindell@ISI.EDU Content-Type: X-sun-attachment Subject: [NSIS] First bug in: draft-braden-2level-signal-arch-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 69 Hi. We have found the first bug (;-)) in the revised 2level signaling draft. The bug is in the definitions of signaling messages xSig() on page 17: all the messages that carry an SAPUid but NOT an SAPU should carry a LIST of SAPUids ("SAPUid-list"). This is a signficant efficiency hack. It allows a single REFRESH message, in particular, to refresh a whole boatload of state in one message. Here is the revised table of messages: xSig(NEW, h-src, SAPUid, SAPU, R) xSig(MOD, h-src, SAPUid, SAPU, old-SAPUid, R) xSig(TEAR, h-src, SAPUid-list) xSig(REFRESH, h-src, SAPUid-list, R) xSig(ACK, h-dest, SAPUid-list) xSig(NACK, h-src, SAPUid-list) xSig(INFO, h-src, SAPUid, SAPU) xSig(EVENT, h-src, SAPUid, SAPU) xSig(CHALLENGE, h-src, challenge-object) xSig(RESPONSE, h-src, challenge-object) xSig(ERROR, h-dest, SAPUid-list) Bob Braden ----- Begin Included Message ----- From owner-ietf-announce@ietf.org Thu Nov 7 03:49:27 2002 Mime-Version: 1.0 To: IETF-Announce: ; From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-braden-2level-signal-arch-01.txt Date: Thu, 07 Nov 2002 06:21:05 -0500 X-AntiVirus: scanned by AMaViS 0.2.1 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Two-Level Architecture for Internet Signaling Author(s) : B. Braden, B. Lindell Filename : draft-braden-2level-signal-arch-01.txt Pages : 29 Date : 2002-11-6 This memo defines an architectural framework for a wide variety of Internet signaling protocols. This framework has a two-level organization: a common lower layer 'transport' protocol together with a suite of upper-level signaling protocols. The common lower level protocol CSTP (Common Signaling Transport Protocol) provides a transport-like service that may include reliable delivery and soft state management. The upper layer protocols, which implement algorithms and data structures specific to particular signaling applications, are generically called ULSPs (Upper-layer Signaling Protocols). This memo motivates the two-level design and describes the service model, API, and operation of the lower level CSTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-braden-2level-signal-arch-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-braden-2level-signal-arch-01.txt". ----- End Included Message ----- ---------- X-Sun-Data-Type: Multipart X-Sun-Content-Length: 514 X-Sun-Charset: us-ascii X-Sun-Content-Lines: 22 --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-6173935.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-braden-2level-signal-arch-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-braden-2level-signal-arch-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-6173935.I-D@ietf.org> --OtherAccess-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 13:41: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 NAA05660 for ; Thu, 7 Nov 2002 13:41:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7IhB906374 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 13:43: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 gA7Ih9v06357; Thu, 7 Nov 2002 13: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 gA7IcFv06154 for ; Thu, 7 Nov 2002 13:38:15 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05572 for ; Thu, 7 Nov 2002 13:35:40 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA7Ic9a19099; Thu, 7 Nov 2002 10:38:10 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id SAA05634; Thu, 7 Nov 2002 18:38:09 GMT Date: Thu, 7 Nov 2002 18:38:09 GMT Message-Id: <200211071838.SAA05634@gra.isi.edu> To: mshore@cisco.com Subject: Re: [NSIS] Key management Cc: braden@ISI.EDU, nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> I think we're arguing the same thing, but it still comes *> back to decisions that are made in the framework. For *> example, if the transport layer is keying hop-by-hop but you *> want NSIS applications (say, NAT communication) to be able *> to do bidirectional authentication, you face the problem of *> getting keys between the NAT, which may be more than one hop *> away from the NSIS initiator, and the NSIS initiator *> itself. *> Melinda, Hmmm. Isn't this just another NAT breakage? Is there a solution to the problem of authentication through NATs? Is the problem of NAT interaction with hop/hop security of signaling fundamentally different from NAT interaction with, say, IPsec? I ask because I really don't understand the problem space here. Thanks, Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 14:05: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 OAA06407 for ; Thu, 7 Nov 2002 14:05:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7J77I08408 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 14:07: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 gA7J75v08314; Thu, 7 Nov 2002 14:07: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 gA7Ixbv07786 for ; Thu, 7 Nov 2002 13:59:38 -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 NAA06267 for ; Thu, 7 Nov 2002 13:57:03 -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 gA7IxWot027835; Thu, 7 Nov 2002 10:59:32 -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 AAS22600; Thu, 7 Nov 2002 10:54:44 -0800 (PST) Message-Id: <200211071854.AAS22600@mira-sjc5-4.cisco.com> To: Bob Braden cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Key management In-Reply-To: Message from Bob Braden of "Thu, 07 Nov 2002 18:38:09 GMT." <200211071838.SAA05634@gra.isi.edu> Date: Thu, 07 Nov 2002 13:59:26 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > Hmmm. Isn't this just another NAT breakage? Is there a solution to > the problem of authentication through NATs? Is the problem of > NAT interaction with hop/hop security of signaling fundamentally > different from NAT interaction with, say, IPsec? I ask because I > really don't understand the problem space here. There are several NAT-related problems with IPSec, and I don't think they necessarily relate here. One is the well-known AH problem. One that's more closely-related and maybe could be used as an object lesson in what not to do is that NAT breaks IKE phase 2 - the addresses being used as in the ID payload are the inside-of-the NAT addresses. To be honest I haven't been following how this is being fixed by the ipsec working group - I need to check it out. For identity authentication we're going to match who they say they are (probably a string of some sort) with the key that they're using, so we don't depend on addresses at all. We may even end up relying on certs. Some of this is going to depend on how discovery and routing are handled. I continue to think that this is something that RSVP got right, or at least I think it will work for our purposes as I outlined in the couple of drafts I've written on the topic. Aside from the question of what we use as the basis for identity I think that we're far, far more likely to be able to work with NATs if the NATs participate - that is to say, we can talk to them, authenticate them, and ask them what our external address will be (for the purposes of embedding in the payload and calculating whatever checksums or HMACs are needed). Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 14:47: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 OAA08041 for ; Thu, 7 Nov 2002 14:47:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7JnRh11940 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 14:49: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 gA7JnPv11903; Thu, 7 Nov 2002 14:49: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 gA7Jj2v11687 for ; Thu, 7 Nov 2002 14:45:02 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07825 for ; Thu, 7 Nov 2002 14:42:27 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA7Jiua01217; Thu, 7 Nov 2002 11:44:56 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id TAA05670; Thu, 7 Nov 2002 19:44:56 GMT Date: Thu, 7 Nov 2002 19:44:56 GMT Message-Id: <200211071944.TAA05670@gra.isi.edu> To: braden@ISI.EDU, nsis@ietf.org Subject: Re: [NSIS] Key management X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , With respect to hop/hop security in NSIS protocols: you should be aware of the experience in the RSVP WG. We were asked, "Why don't you just use IPsec?", and we wondered why indeed. Why spend the energy to think through the issues of getting replay protection right, for example, if the security folks have already produced a solution? It turned out that IPsec as currently defined was not directly applicable to the hop/hop case. It seemed quite possible to define a third form of IPsec for this purpose, but the security folks were not particularly interested in helping the QoS folks with their problem. As a result, the RSVP WG was forced to roll their own (RFC 2747). Maybe that decision can/should be revisited in NSIS. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 14:53: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 OAA08320 for ; Thu, 7 Nov 2002 14:53:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7JtG312304 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 14:55: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 gA7Jt3v12276; Thu, 7 Nov 2002 14:55: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 gA7Jskv12247 for ; Thu, 7 Nov 2002 14:54:46 -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 OAA08276 for ; Thu, 7 Nov 2002 14:52:10 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA7JsePP027877; Thu, 7 Nov 2002 11:54:40 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAN52119; Thu, 7 Nov 2002 11:48:54 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA14096; Thu, 7 Nov 2002 11:54:39 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15818.50431.435862.532830@thomasm-u1.cisco.com> Date: Thu, 7 Nov 2002 11:54:39 -0800 (PST) To: Bob Braden Cc: nsis@ietf.org Subject: Re: [NSIS] Key management In-Reply-To: <200211071944.TAA05670@gra.isi.edu> References: <200211071944.TAA05670@gra.isi.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bob Braden writes: > > With respect to hop/hop security in NSIS protocols: you should be aware > of the experience in the RSVP WG. We were asked, "Why don't you just > use IPsec?", and we wondered why indeed. Why spend the energy to think > through the issues of getting replay protection right, for example, if > the security folks have already produced a solution? > > It turned out that IPsec as currently defined was not directly > applicable to the hop/hop case. It seemed quite possible to define a > third form of IPsec for this purpose, but the security folks were not > particularly interested in helping the QoS folks with their problem. > As a result, the RSVP WG was forced to roll their own (RFC 2747). > Maybe that decision can/should be revisited in NSIS. FYI, Steve Bellovin just published a draft *-useipsec-00.txt which is probably relevant to this. Do you happen to recall the reasons why there was pushback? I suspect I know, but it would be good to hear it. Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 15:03: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 PAA08752 for ; Thu, 7 Nov 2002 15:03:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7K5PC13071 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 15:05: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 gA7K5Nv13050; Thu, 7 Nov 2002 15:05:23 -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 gA7K4vv12987 for ; Thu, 7 Nov 2002 15:04:57 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08704 for ; Thu, 7 Nov 2002 15:02:21 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA7K4pa14327 for ; Thu, 7 Nov 2002 12:04:51 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id UAA05716 for nsis@ietf.org; Thu, 7 Nov 2002 20:04:51 GMT Date: Thu, 7 Nov 2002 20:04:51 GMT Message-Id: <200211072004.UAA05716@gra.isi.edu> To: nsis@ietf.org Subject: RE: [NSIS] Key management X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> > *> > BTW, we should think about the performance implications of *> > doing a key exchange in the transport layer + a key exchange *> > in the application layer. *> *> we should always keep performance in mind. hence i argue that it might not *> the most performance efficient approach to have security at both layers if *> they terminate at the same endpoints. *> I don't see an issue here, in terms of mechanism. The hash code used for a hop/hop mechanism for integrity or the encryption for confidentiality can cover the application layer information as well as the transport layer. In terms of my model, it can cover the SAPU as well as any fields of the CSTP header that you want to protect. So there will be one key. Of course, all of this is distinct from end user authentication, which is almost certainly a PK problem. *> we should, however, have no illusion about the fact that an authentication *> and key exchange is associated with some cost. keys and security *> associations do not appear by magic. *> *> related to performance i would also like to point a typical approach in this *> area (and other area as well): to establishment a security association which *> can then be used to protect signaling messages (or parts of it) *> the benefit of this approach is that an authentication and key establishment *> is done once. protection of a possibly large number of signaling message can *> then done by very efficient means. *> That is indeed a property of hop/hop security. However, when you say authentication here, you cannot be talking about user authentication, you must be talking about NSIS neighbor authentication. Bob Braden ----- End Included Message ----- ----- End Included Message ----- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 17:40: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 RAA16462 for ; Thu, 7 Nov 2002 17:40:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7Mgnc27335 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 17:42: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 gA7Mgkv27328; Thu, 7 Nov 2002 17: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 gA7Manv26457 for ; Thu, 7 Nov 2002 17:36:49 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16270 for ; Thu, 7 Nov 2002 17:34:13 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Nov 2002 22:36:41 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5DA2@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Bob Braden , nsis@ietf.org, brunner@ccrle.nec.de Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Thu, 7 Nov 2002 22:36:41 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi, A comment on scope/layering of this reservation identifier thing (if it ever exists): > *> So reformulating the requirement into "An NSIS protocol > MUST support a > *> reservation identifer" would solve the first one. > > OK, although I would say "MUST be able to support". > > BTW, a reservation identifier is presumably a multi-hop > thing, so in my > 2-level model it is a creature of ULSP, i.e., it is carried in an > SAPU. That's good, because non-QoS signaling applications probably > don't have any reservations to identify. I think we need to work through this. 1. As Marcus has said, we are signalling to set up something, and that something is what we want to identify to be able to manipulate - it doesn't matter if it's QoS (and called a reservation) or something else. The v6 flow label draft calls this something 'flow state' so this identifier could be a "flow state id". Would that be a better term? 2. My feeling is that this XXX-id would be useful for general signalling applications (i.e. if you use the signalling application in a mobile enviroment, efficiently moving the state is something you want to do anyway). Also, providing the facility might be tricky, and might require subtle interworking with other protocols (e.g. mobility ones). In that case, it be better to provide it as a generic service rather than solving the problem for each signalling application. 3. So, wouldn't one want it within the NTLP (lower layer)? 4. Or, should we be thinking of some kind of 'core' NSLP toolkit which has these generic facilities? Cheers, Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 17:48: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 RAA16762 for ; Thu, 7 Nov 2002 17:48:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA7Mo8B27664 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 17:50: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 gA7Mo6v27657; Thu, 7 Nov 2002 17:50: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 gA7MnLv27601 for ; Thu, 7 Nov 2002 17:49:21 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16700 for ; Thu, 7 Nov 2002 17:46:45 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA7MnCa22839; Thu, 7 Nov 2002 14:49:12 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id WAA06054; Thu, 7 Nov 2002 22:49:12 GMT Date: Thu, 7 Nov 2002 22:49:12 GMT Message-Id: <200211072249.WAA06054@gra.isi.edu> To: braden@ISI.EDU, nsis@ietf.org, robert.hancock@roke.co.uk Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> I think we need to work through this. *> *> 1. As Marcus has said, we are signalling to set up something, and that something is what we want to identify to be able to manipulate - it doesn't matter if it's QoS (and called a reservation) or something else. *> *> The v6 flow label draft calls this something 'flow state' so this identifier could be a "flow state id". Would that be a better term? *> *> 2. My feeling is that this XXX-id would be useful for general signalling applications (i.e. if you use the signalling application in a mobile enviroment, efficiently moving the state is something you want to do anyway). Also, providing the facility might be tricky, and might require subtle interworking with other protocols (e.g. mobility ones). *> *> In that case, it be better to provide it as a generic service rather than solving the problem for each signalling application. *> *> 3. So, wouldn't one want it within the NTLP (lower layer)? *> 4. Or, should we be thinking of some kind of 'core' NSLP toolkit which has these generic facilities? *> *> Cheers, *> *> Robert H. Robert, The architectural principle in CSTP is that it operates hop/hop. This turns out to capture a lot of generic functionality, which is its benefit. That does not mean that all generic functionality belongs in CSTP, particularly generic E2E functionality. So I can see several alternatives: (1) Overload CSTP (I mean overload in the technical sense, not the pejorative sense) by putting any important generic functionality in CSTP. This effectively gives the CSTP level a second major architectural task, in addition to handling hop/hop transport. The effect on the spec would be to add calls to the API for the library of generic functionsI. Note that my latest draft suggests doing exactly this for the interface to routing, which is probably of importance to both levels. However, I think that is a somewhat different case, since routing is really a hop/hop issue although it has to be available to the ULSP. (2) Create some additional structure in the upper level, for example a library of common generic functions. I suggest that (2) is architecturally preferable, for the following reason. We may expect that over time additional generic functions will be defined and some will be modified, as the IETF develops different ULSPs. But you really don't want to decouple these changes from the API to the CSTP, which you want to be as stable as possible. Hope this helps, Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 18:59: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 SAA18672 for ; Thu, 7 Nov 2002 18:59:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA801RR31088 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 19:01: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 gA801Pv31081; Thu, 7 Nov 2002 19:01: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 gA800kv31045 for ; Thu, 7 Nov 2002 19:00:46 -0500 Received: from mailrelay1.alcatel.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18650 for ; Thu, 7 Nov 2002 18:58:09 -0500 (EST) From: Axel.Kuttner@alcatel.de Received: from slsas5.stgl.netd.alcatel.de (slsas5.stgl.netd.alcatel.de [149.204.45.57]) by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id BAA03209 for ; Fri, 8 Nov 2002 01:00:37 +0100 (MET) To: nsis@ietf.org Message-ID: Date: Fri, 8 Nov 2002 01:00:34 +0100 X-MIMETrack: Serialize by Router on DEMTA001/DE/ALCATEL(Release 5.0.9 |November 16, 2001) at 11/08/2002 01:00:37 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes Subject: [NSIS] Axel KUTTNER/DE/ALCATEL is out of the office. Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , I will be out of the office starting 07.11.2002 and will not return until 10.11.2002. Thank you for keeping me informed. I will respond to your message when I return. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 7 23:14: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 XAA24464 for ; Thu, 7 Nov 2002 23:14:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA84GKa14151 for nsis-archive@odin.ietf.org; Thu, 7 Nov 2002 23:16: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 gA84GIv14128; Thu, 7 Nov 2002 23: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 gA7KZ3v15476 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: [NSIS] Note Well Statement Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling 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. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 01:54: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 BAA28663 for ; Fri, 8 Nov 2002 01:54:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA86uPn22736 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 01:56: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 gA86uNv22716; Fri, 8 Nov 2002 01:56:23 -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 gA86t1v22672 for ; Fri, 8 Nov 2002 01:55:01 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28627 for ; Fri, 8 Nov 2002 01:52:20 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA86sMO06497 for ; Fri, 8 Nov 2002 08:54:22 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 8 Nov 2002 08:54:49 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 08:54:49 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 08:54:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 8 Nov 2002 08:54:48 +0200 Message-ID: Thread-Topic: [NSIS] Key management Thread-Index: AcKGY6l/k3IUEvyITVu+w2c0RNXdtQAj9CtQ To: X-OriginalArrivalTime: 08 Nov 2002 06:54:49.0249 (UTC) FILETIME=[BB02C110:01C286F3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA86t1v22673 Subject: [NSIS] Call for help at IETF 55 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, One thing that I would like to discuss at IETF 55 is terminology. A short 10 minute discussion, capturing some of the terminology discussions we have had, would be useful. Anyone interested in pulling together some of the open terms & leading the discussion? Send me email. Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 01:54: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 BAA28686 for ; Fri, 8 Nov 2002 01:54:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA86v4j22847 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 01:57: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 gA86v2v22807; Fri, 8 Nov 2002 01:57: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 gA86uSv22748 for ; Fri, 8 Nov 2002 01:56:28 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28639 for ; Fri, 8 Nov 2002 01:53:47 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA86unB10273 for ; Fri, 8 Nov 2002 08:56:50 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Nov 2002 08:56:16 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 08:56:14 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 08:56:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Comment : RSVP Analysis Draft Date: Fri, 8 Nov 2002 08:56:13 +0200 Message-ID: Thread-Topic: [NSIS] Comment : RSVP Analysis Draft Thread-Index: AcKGY6y6rYLWDb9ZTayi+ZGiDPyVGQAkCBcQ To: , Cc: X-OriginalArrivalTime: 08 Nov 2002 06:56:13.0968 (UTC) FILETIME=[ED81D900:01C286F3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA86uSv22749 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, > I am currently doing my Master Thesis at Siemens AG, Munich > under Dresden University of Technology and work focus is QoS > on access networks which is related to the EU project AQUILA > (http://www.ist-aquila.org/). > > The thesis also comes up with a comparison between RSVP, > YESSIR and Boomerang in access network scenarios and in my > study I have come to the conclusion that RSVP in spite of its > complex architecture can still be efficiently used in Access > and some other architecture in the core network, like AQUILA. > Though YESSIR presents a more efficient alternative to RSVP, > but due to it being signaled over RTP, only multimedia > traffic can be guaranteed QoS, and if traffic independent QoS > is required then it does not serve the purpose. Though > Boomerang offers a very efficient architecture but the wide > support of RSVP on routers and OS plays towards its favor. > The major complexity of RSVP starts in the core where the > number of flows increases drastically, but in access where > the flows are limited, it can efficiently be used. > > In the work I make relevant changes to terminate RSVP in the > ingress access and start a AQUILA session on the edge router > for core and then re-start RSVP on egress to complete edge to > edge QoS. In further work I would try to prove that this > solution is better than pure RSVP solution. > I think the work might be of interest to NSIS for further discussion. If you could comment on the current Analysis draft and suggest some text, that would be very helpful. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 03:11: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 DAA10099 for ; Fri, 8 Nov 2002 03:11:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA88DPF04157 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 03:13: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 gA88DMv04142; Fri, 8 Nov 2002 03:13: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 gA88CFv04098 for ; Fri, 8 Nov 2002 03:12:15 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10048 for ; Fri, 8 Nov 2002 03:09:33 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA88CKB20539 for ; Fri, 8 Nov 2002 10:12:34 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Nov 2002 10:11:43 +0200 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 10:11:44 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 10:11:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt Date: Fri, 8 Nov 2002 10:11:39 +0200 Message-ID: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt Thread-Index: AcKGexXprE3V37V5RnKUDpV7ppf41QAgnoaA To: Cc: X-OriginalArrivalTime: 08 Nov 2002 08:11:40.0018 (UTC) FILETIME=[773E4520:01C286FE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA88CFv04099 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Vlora, > Is this draft really an NSIS WG draft or is it just the > name that is misleading? It is a WG draft. I discussed with our ADs about the lack of progress on some of our charter items, and it was suggested that a good editor for this work would be important, especially a non-biased one. As you know, RSVP has been labeled many things (not scalable, etc) that are incorrect, so having an unbiased editor is critical for this work. At IETF 54, there was general consensus on moving forward with this work, and taking Xiaoming Fu's document on Multicast analysis into the WG document. As I have understood, Jukka was short on time, so he may not have solicitied input from other folks - however, now would be a perfect time to comment, criticize or suggest text to the document. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 03:16: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 DAA10164 for ; Fri, 8 Nov 2002 03:16:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA88J8G04361 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 03:19: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 gA88J5v04354; Fri, 8 Nov 2002 03:19: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 gA88I5v04294 for ; Fri, 8 Nov 2002 03:18:05 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10149 for ; Fri, 8 Nov 2002 03:15:23 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA88HPO06412 for ; Fri, 8 Nov 2002 10:17:25 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Nov 2002 10:17:50 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 10:17:26 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 10:17:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] First bug in: draft-braden-2level-signal-arch-01.txt Date: Fri, 8 Nov 2002 10:17:25 +0200 Message-ID: Thread-Topic: [NSIS] First bug in: draft-braden-2level-signal-arch-01.txt Thread-Index: AcKGjLR1ib9J6Z9TSXyo3VVk3OJ+2QAcn5ig To: , Cc: X-OriginalArrivalTime: 08 Nov 2002 08:17:26.0283 (UTC) FILETIME=[45A21DB0:01C286FF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA88I5v04295 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Resending this to the list: > -----Original Message----- > From: ext Bob Braden [mailto:braden@ISI.EDU] > Sent: 07 November, 2002 20:31 > To: nsis@ietf.org > Cc: braden@ISI.EDU; lindell@ISI.EDU > Subject: [NSIS] First bug in: draft-braden-2level-signal-arch-01.txt Hi. We have found the first bug (;-)) in the revised 2level signaling draft. The bug is in the definitions of signaling messages xSig() on page 17: all the messages that carry an SAPUid but NOT an SAPU should carry a LIST of SAPUids ("SAPUid-list"). This is a signficant efficiency hack. It allows a single REFRESH message, in particular, to refresh a whole boatload of state in one message. Here is the revised table of messages: xSig(NEW, h-src, SAPUid, SAPU, R) xSig(MOD, h-src, SAPUid, SAPU, old-SAPUid, R) xSig(TEAR, h-src, SAPUid-list) xSig(REFRESH, h-src, SAPUid-list, R) xSig(ACK, h-dest, SAPUid-list) xSig(NACK, h-src, SAPUid-list) xSig(INFO, h-src, SAPUid, SAPU) xSig(EVENT, h-src, SAPUid, SAPU) xSig(CHALLENGE, h-src, challenge-object) xSig(RESPONSE, h-src, challenge-object) xSig(ERROR, h-dest, SAPUid-list) Bob Braden ----- Begin Included Message ----- From owner-ietf-announce@ietf.org Thu Nov 7 03:49:27 2002 Mime-Version: 1.0 To: IETF-Announce: ; From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-braden-2level-signal-arch-01.txt Date: Thu, 07 Nov 2002 06:21:05 -0500 X-AntiVirus: scanned by AMaViS 0.2.1 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Two-Level Architecture for Internet Signaling Author(s) : B. Braden, B. Lindell Filename : draft-braden-2level-signal-arch-01.txt Pages : 29 Date : 2002-11-6 This memo defines an architectural framework for a wide variety of Internet signaling protocols. This framework has a two-level organization: a common lower layer 'transport' protocol together with a suite of upper-level signaling protocols. The common lower level protocol CSTP (Common Signaling Transport Protocol) provides a transport-like service that may include reliable delivery and soft state management. The upper layer protocols, which implement algorithms and data structures specific to particular signaling applications, are generically called ULSPs (Upper-layer Signaling Protocols). This memo motivates the two-level design and describes the service model, API, and operation of the lower level CSTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-braden-2level-signal-arch-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-braden-2level-signal-arch-01.txt". ----- End Included Message ----- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 03:49: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 DAA10716 for ; Fri, 8 Nov 2002 03:49:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA88pIm06311 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 03:51: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 gA88pDv06286; Fri, 8 Nov 2002 03:51: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 gA88okv06270 for ; Fri, 8 Nov 2002 03:50:46 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10708 for ; Fri, 8 Nov 2002 03:48:05 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gA88oXU24241; Fri, 8 Nov 2002 09:50:33 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gA88oXB23182; Fri, 8 Nov 2002 09:50:33 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Melinda Shore" , "Bob Braden" Cc: Subject: RE: [NSIS] Key management Date: Fri, 8 Nov 2002 09:51:40 +0100 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) In-Reply-To: <200211071854.AAS22600@mira-sjc5-4.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi melinda! i agree with you that there are problems with nat and ipsec. for a nsis signaling protocol nat is generally a problem - not only for ipsec. even if you get a proper security protection (which is possible) then you still have the problem that you make a reservation for the wrong data traffic. i should also be pointed out that tunneling solutions to fix this problem have been proposed. furthermore it should be noted that the problem depends how you deploy a nsis protocol and nats. if the nat is nsis aware then there does not seem to be a problem. your remark regarding rsvp was not clear to me. in rsvp you select your key for the integrity object based on an ip address. ciao hannes > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Melinda Shore > Sent: Thursday, November 07, 2002 7:59 PM > To: Bob Braden > Cc: nsis@ietf.org > Subject: Re: [NSIS] Key management > > > > Hmmm. Isn't this just another NAT breakage? Is there a solution to > > the problem of authentication through NATs? Is the problem of > > NAT interaction with hop/hop security of signaling fundamentally > > different from NAT interaction with, say, IPsec? I ask because I > > really don't understand the problem space here. > > There are several NAT-related problems with IPSec, and I > don't think they necessarily relate here. One is the > well-known AH problem. One that's more closely-related and > maybe could be used as an object lesson in what not to do is > that NAT breaks IKE phase 2 - the addresses being used as > in the ID payload are the inside-of-the NAT addresses. To > be honest I haven't been following how this is being > fixed by the ipsec working group - I need to check it out. > > For identity authentication we're going to match who they > say they are (probably a string of some sort) with the key > that they're using, so we don't depend on addresses at all. > We may even end up relying on certs. Some of this is going > to depend on how discovery and routing are handled. I > continue to think that this is something that RSVP got > right, or at least I think it will work for our purposes as > I outlined in the couple of drafts I've written on the > topic. > > Aside from the question of what we use as the basis for > identity I think that we're far, far more likely to be able > to work with NATs if the NATs participate - that is to say, > we can talk to them, authenticate them, and ask them what > our external address will be (for the purposes of embedding > in the payload and calculating whatever checksums or HMACs > are needed). > > Melinda > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 03:49: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 DAA10722 for ; Fri, 8 Nov 2002 03:49:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA88pJN06323 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 03:51:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA88pEv06302; Fri, 8 Nov 2002 03:51: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 gA88ojv06266 for ; Fri, 8 Nov 2002 03:50:45 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10707 for ; Fri, 8 Nov 2002 03:48:05 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id gA88oXn21547; Fri, 8 Nov 2002 09:50:33 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gA88oXB23176; Fri, 8 Nov 2002 09:50:33 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Bob Braden" , Subject: RE: [NSIS] Key management Date: Fri, 8 Nov 2002 09:51:40 +0100 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) In-Reply-To: <200211071944.TAA05670@gra.isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi bob! > > With respect to hop/hop security in NSIS protocols: you should be aware > of the experience in the RSVP WG. We were asked, "Why don't you just > use IPsec?", and we wondered why indeed. Why spend the energy to think > through the issues of getting replay protection right, for example, if > the security folks have already produced a solution? > > It turned out that IPsec as currently defined was not directly > applicable to the hop/hop case. i would like to know in which area you saw a problem with ipsec processing. i see some problems when using ipsec with rsvp: this is related to the path message. to protect an rsvp message you would have to install a traffic selector for ipsec. it cannot be based the destination address or the port since it is not the one of the next peer. hence if you have more than two choices for a path you do not know where the message go. in case that you have a single router (e.g. default router) to which you send your signaling messages then everything is fine. > It seemed quite possible to define a > third form of IPsec for this purpose, but the security folks were not > particularly interested in helping the QoS folks with their problem. what do you mean by third form? > As a result, the RSVP WG was forced to roll their own (RFC 2747). > Maybe that decision can/should be revisited in NSIS. > ciao hannes > Bob Braden > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 03:59: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 DAA10927 for ; Fri, 8 Nov 2002 03:59:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA891JG06712 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 04:01:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA891Ev06705; Fri, 8 Nov 2002 04:01: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 gA890ov06672 for ; Fri, 8 Nov 2002 04:00:50 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10919 for ; Fri, 8 Nov 2002 03:58:09 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gA890bU01141; Fri, 8 Nov 2002 10:00:37 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gA890bB02852; Fri, 8 Nov 2002 10:00:37 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Bob Braden" , Subject: RE: [NSIS] Key management Date: Fri, 8 Nov 2002 10:01:44 +0100 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) In-Reply-To: <200211072004.UAA05716@gra.isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi bob! please find my comments inline: > > *> > > *> > BTW, we should think about the performance implications of > *> > doing a key exchange in the transport layer + a key exchange > *> > in the application layer. > *> > *> we should always keep performance in mind. hence i argue > that it might not > *> the most performance efficient approach to have security at > both layers if > *> they terminate at the same endpoints. > *> > I don't see an issue here, in terms of mechanism. The hash code used > for a hop/hop mechanism for integrity or the encryption for > confidentiality > can cover the application layer information as well as the transport > layer. that's my argument. i only want to point to this issue since some people argue that you only need to protect the application layer. you can protect both layers without a problem. why only to protect one? In terms of my model, it can cover the SAPU as well as any fields > of the CSTP header that you want to protect. So there will be one key. this is definitely true. > Of course, all of this is distinct from end user authentication, which > is almost certainly a PK problem. not necessarily. a pk-problem will arise if you want any router/network along the path to authenticate the user authentication. for the first peer protection there is no pki problem. > > *> we should, however, have no illusion about the fact that an > authentication > *> and key exchange is associated with some cost. keys and security > *> associations do not appear by magic. > *> > *> related to performance i would also like to point a typical > approach in this > *> area (and other area as well): to establishment a security > association which > *> can then be used to protect signaling messages (or parts of it) > *> the benefit of this approach is that an authentication and > key establishment > *> is done once. protection of a possibly large number of > signaling message can > *> then done by very efficient means. > *> > > That is indeed a property of hop/hop security. this can be considered independently of hop-by-hop security protection. for example: if you use rsvp and pk-based mechanisms then you do not establish a security association. hence you have expensive processing every time you include a digital signature. in case of kerberos rsvp proposes to store the session key of the ticket to avoid sending the service ticket every time. > However, when you say > authentication here, you cannot be talking about user authentication, > you must be talking about NSIS neighbor authentication. it depends who is the signaling initiator. if the signaling initiator is the end point then it must be user authentication since otherwise you cannot perform policy based admission control (+accounting). in case of other nodes along the path the identity is not the user. ciao hannes > > Bob Braden > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 04:11: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 EAA11133 for ; Fri, 8 Nov 2002 04:11:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA89DDw07996 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 04:13: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 gA89DAv07989; Fri, 8 Nov 2002 04:13: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 gA89Cmv07972 for ; Fri, 8 Nov 2002 04:12:48 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11125 for ; Fri, 8 Nov 2002 04:10:07 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 8 Nov 2002 09:38:11 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Nov 2002 09:38:11 +0100 Message-Id: From: "Geib, Ruediger" To: Hannes.Tschofenig@siemens.com Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Date: Fri, 8 Nov 2002 09:38:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA89Cmv07973 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello Hannes > for example: > if the only purpose of the relay is to forward the message without > processing nsis specific parts then there is no reason to > have this entity as a nsis node. if the relay might even > modify the message then there is no > reason why not to treat it as a regular nsis entity. My ideas: The relay should be NSIS aware. It discovers NSIS CSTP neighbors. It forwards messages there. This may, but doesn't have to include a change in the next hop address. It has to be able to support all functions required to keep alive CSTP signaling relations to its neighbors (i.e. some operational features). The relay is not involved into any service management. Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 04:20: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 EAA11265 for ; Fri, 8 Nov 2002 04:20:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA89MBP08387 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 04:22: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 gA89M8v08376; Fri, 8 Nov 2002 04:22: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 gA89Lqv08357 for ; Fri, 8 Nov 2002 04:21:52 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11235 for ; Fri, 8 Nov 2002 04:19:11 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA89LeQ1025779; Fri, 8 Nov 2002 10:21:40 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WPTG2AZM; Fri, 8 Nov 2002 10:21:39 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Nov 2002 10:21:39 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE18A@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 419f1c10 ca231590 d342b509 00000138 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" Cc: "'nsis@ietf.org'" , "Vlora Rexhepi (ELN)" Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt Date: Fri, 8 Nov 2002 10:21:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi John We really want to contribute to the WG draft. The draft draft-demeer-nsis-analysis-03.txt could be used as our contribution to the WG draft. This draft is located at: http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-03.txt Best Regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: vrijdag 8 november 2002 9:12 To: Vlora.Rexhepi@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt Hi Vlora, > Is this draft really an NSIS WG draft or is it just the > name that is misleading? It is a WG draft. I discussed with our ADs about the lack of progress on some of our charter items, and it was suggested that a good editor for this work would be important, especially a non-biased one. As you know, RSVP has been labeled many things (not scalable, etc) that are incorrect, so having an unbiased editor is critical for this work. At IETF 54, there was general consensus on moving forward with this work, and taking Xiaoming Fu's document on Multicast analysis into the WG document. As I have understood, Jukka was short on time, so he may not have solicitied input from other folks - however, now would be a perfect time to comment, criticize or suggest text to the document. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 04:33: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 EAA11447 for ; Fri, 8 Nov 2002 04:33:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA89ZFp09062 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 04:35:15 -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 gA89ZBv09052; Fri, 8 Nov 2002 04:35: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 gA89Ynv09018 for ; Fri, 8 Nov 2002 04:34:49 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11440 for ; Fri, 8 Nov 2002 04:32:08 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA89YbQ1000202; Fri, 8 Nov 2002 10:34:37 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WPTS6DF5; Fri, 8 Nov 2002 10:34:36 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Nov 2002 10:34:36 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE18B@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 8ef78691 ca231590 d342b509 00000138 From: "Georgios Karagiannis (ELN)" To: "'Melinda Shore'" , "Geib, Ruediger" Cc: Hannes.Tschofenig@siemens.com, nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Date: Fri, 8 Nov 2002 10:34:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi all I agree with Melinda that encryption, and in general security issues, could be seen as application layer functionality. This is also applied in the draft: http://www.ietf.org/internet-drafts/draft-westberg-proposal-for-rsvpv2-01.txt Best regards, Georgios -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: woensdag 6 november 2002 16:30 To: Geib, Ruediger Cc: Hannes.Tschofenig@siemens.com; nsis@ietf.org Subject: Re: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages > To me, a simple relay doesn't have to operate encryption. The correct answer to any technical question is "it depends," and I think it this case it comes down to depending on how the application layer is split from the transport layer, what information is contained in the transport layer, and if the information that a relay would need to forward the message correctly is itself encrypted. My suspicion is that the information one might want to protect from prying eyes will tend to be carried in the application, and that any information that could be derived from looking at transport layer daya could also be derived from traffic analysis. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 04:54: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 EAA11765 for ; Fri, 8 Nov 2002 04:54:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA89v7810546 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 04:57: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 gA89v5v10522; Fri, 8 Nov 2002 04:57: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 gA89mUv10228 for ; Fri, 8 Nov 2002 04:48:30 -0500 Received: from s2 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11638 for ; Fri, 8 Nov 2002 04:45:49 -0500 (EST) Received: from ap12 (ap12.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.44]) by s2 with esmtp; Fri, 08 Nov 2002 10:48:18 +0100 From: "Xiaoming Fu" To: "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: Re: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Date: Fri, 8 Nov 2002 10:47:16 +0100 Message-ID: <000e01c2870b$d2d80e40$2c514c86@ap12> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA89mUv10229 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Rüdiger, > > for example: > > if the only purpose of the relay is to forward the message without > > processing nsis specific parts then there is no reason to have this > > entity as a nsis node. if the relay might even modify the > message then > > there is no reason why not to treat it as a regular nsis entity. > > My ideas: > The relay should be NSIS aware. It discovers NSIS CSTP neighbors. > It forwards messages there. This may, but doesn't have to include > a change in the next hop address. It has to be able to support all > functions required to keep alive CSTP signaling relations to its > neighbors (i.e. some operational features). > The relay is not involved into any service management. I don't think a relay node should always be NSIS aware. My understanding is a CSTP-speaking node before this relay node (along the data path) can discovery next CSTP hop by its own discovery mechanism; the relationship between CSTP signaling neighbors is maintained by themselves. Relay-only node can simply forward the signaling message as a normal IP packet. Regards, Xiaoming > > Regards, Rüdiger > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 04:54: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 EAA11778 for ; Fri, 8 Nov 2002 04:54:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA89v9910585 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 04:57:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA89v7v10548; Fri, 8 Nov 2002 04:57: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 gA89tov10457 for ; Fri, 8 Nov 2002 04:55:50 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11722 for ; Fri, 8 Nov 2002 04:53:09 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA89tcQ1007775 for ; Fri, 8 Nov 2002 10:55:38 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WPTG2J3Q; Fri, 8 Nov 2002 10:55:37 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Nov 2002 10:55:37 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE18D@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 987ffa45 ca231590 d342b509 00000138 From: "Georgios Karagiannis (ELN)" To: nsis@ietf.org Date: Fri, 8 Nov 2002 10:55:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] NTLP (e.g., CSTP) layer features/functionalities? Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi all In my opinion an important issue that we should discuss is related to which features/functionalities should be supported by the NTLP (e.g., CSTP) layer! The draft-braden-2level-signal-arch-01.txt could be a starting point! Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 05:18: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 FAA12271 for ; Fri, 8 Nov 2002 05:18:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8AKLx12206 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 05:20:21 -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 gA8AKJv12199; Fri, 8 Nov 2002 05:20: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 gA8AJAv12111 for ; Fri, 8 Nov 2002 05:19:10 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12225 for ; Fri, 8 Nov 2002 05:16:39 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 8 Nov 2002 11:18:33 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Nov 2002 11:18:06 +0100 Message-Id: From: "Geib, Ruediger" To: braden@ISI.EDU Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Fri, 8 Nov 2002 11:18:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA8AJAv12112 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Bob, I support your view on the issue. Regards, Rüdiger > The architectural principle in CSTP is that it operates hop/hop. > This turns out to capture a lot of generic functionality, which is > its benefit. That does not mean that all generic > functionality belongs > in CSTP, particularly generic E2E functionality. > > So I can see several alternatives: > > (1) Overload CSTP (I mean overload in the technical sense, not the > pejorative sense) by putting any important generic > functionality in CSTP. This effectively gives the CSTP level a > second major architectural task, in addition to handling > hop/hop transport. The effect on the spec would be to add > calls to the API for the library of generic functionsI. > > Note that my latest draft suggests doing exactly this for the > interface to routing, which is probably of importance to both > levels. However, I think that is a somewhat different case, > since routing is really a hop/hop issue although it has to > be available to the ULSP. > > (2) Create some additional structure in the upper level, for example a > library of common generic functions. > > I suggest that (2) is architecturally preferable, for the following > reason. We may expect that over time additional generic > functions will > be defined and some will be modified, as the IETF develops different > ULSPs. But you really don't want to decouple these changes from the > API to the CSTP, which you want to be as stable as possible. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 05:31: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 FAA12439 for ; Fri, 8 Nov 2002 05:31:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8AXOP12675 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 05:33: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 gA8AXMv12668; Fri, 8 Nov 2002 05:33: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 gA8AWav12642 for ; Fri, 8 Nov 2002 05:32:36 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12427 for ; Fri, 8 Nov 2002 05:30:05 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA8AWXKV025394; Fri, 8 Nov 2002 11:32:33 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WPTG2R65; Fri, 8 Nov 2002 11:32:33 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Nov 2002 11:25:39 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C022BCE4@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: a2d2cb34 ca231590 d342b509 00000138 From: "Vlora Rexhepi (ELN)" To: "'john.loughney@nokia.com'" Cc: nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt Date: Fri, 8 Nov 2002 11:32:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi John, |It is a WG draft. I discussed with our ADs about the lack |of progress on some of our charter items, and it was suggested |that a good editor for this work would be important, especially |a non-biased one. As you know, RSVP has been labeled many |things (not scalable, etc) that are incorrect, so having an |unbiased editor is critical for this work. I understand. |As I have understood, Jukka was short on time, so he may not |have solicitied input from other folks - however, now would |be a perfect time to comment, criticize or suggest text to |the document. I still haven't read the draft, but I will do that shortly. As Georgios said we can definitely contribute to this draft. Regards, Vlora _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 05:50: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 FAA12634 for ; Fri, 8 Nov 2002 05:50:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8Aq7J13936 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 05:52: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 gA8Aq6v13925; Fri, 8 Nov 2002 05:52: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 gA8ApPv13888 for ; Fri, 8 Nov 2002 05:51:25 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12619 for ; Fri, 8 Nov 2002 05:48:53 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA8AptB09389 for ; Fri, 8 Nov 2002 12:51:55 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Nov 2002 12:51:18 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 12:51:20 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 12:51:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt Date: Fri, 8 Nov 2002 12:51:19 +0200 Message-ID: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt Thread-Index: AcKHEkuQIKN0HWkTS+G/iR8KjcRDWgAAmYWg To: Cc: X-OriginalArrivalTime: 08 Nov 2002 10:51:20.0226 (UTC) FILETIME=[C57E0020:01C28714] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA8ApPv13889 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Vlora, > |As I have understood, Jukka was short on time, so he may not > |have solicitied input from other folks - however, now would > |be a perfect time to comment, criticize or suggest text to > |the document. > I still haven't read the draft, but I will do that shortly. > As Georgios said we can definitely contribute to this draft. That would be great. I think suggesting text, additional things to consider, etc. would be extremely helpful. thanks! JOhn _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 05:51: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 FAA12660 for ; Fri, 8 Nov 2002 05:51:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8Ar3P13989 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 05:53: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 gA8Ar1v13977; Fri, 8 Nov 2002 05:53: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 gA8AqGv13952 for ; Fri, 8 Nov 2002 05:52:16 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12632 for ; Fri, 8 Nov 2002 05:49:45 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA8ApkO05474 for ; Fri, 8 Nov 2002 12:51:46 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Nov 2002 12:52:14 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 12:52:12 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 12:52:11 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 12:52:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt Date: Fri, 8 Nov 2002 12:52:10 +0200 Message-ID: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt Thread-Index: AcKHCEqtCzee8l0RRCazeWoWPBHEtgADICRQ To: Cc: , X-OriginalArrivalTime: 08 Nov 2002 10:52:10.0782 (UTC) FILETIME=[E3A03BE0:01C28714] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA8AqGv13953 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Georgios > We really want to contribute to the WG draft. > The draft draft-demeer-nsis-analysis-03.txt could be used as > our contribution to the WG draft. > This draft is located at: > http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-03.txt Great. Please read the other draft and comment on it. If you think you can add text, please contact Jukka and suggest ways to work. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 06:00: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 GAA12839 for ; Fri, 8 Nov 2002 06:00:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8B2Ch14317 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 06:02: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 gA8B2Av14310; Fri, 8 Nov 2002 06:02: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 gA8B1Uv14278 for ; Fri, 8 Nov 2002 06:01:30 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12806 for ; Fri, 8 Nov 2002 05:58:58 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA8B1uB20172 for ; Fri, 8 Nov 2002 13:02:00 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 8 Nov 2002 13:01:23 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 13:01:23 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 13:01:22 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 13:01:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 8 Nov 2002 13:01:08 +0200 Message-ID: Thread-Topic: Off-site participation at IETF 55 / text conferencing Thread-Index: AcKHFiQS04CADu9FSP66gcMqtbT5pw== To: X-OriginalArrivalTime: 08 Nov 2002 11:01:10.0442 (UTC) FILETIME=[2549D0A0:01C28716] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA8B1Uv14279 Subject: [NSIS] Off-site participation at IETF 55 / text conferencing Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, It seems that there will be an attempt to provide multicast plus instant messaging support for IETF 55. What this means is that folks can follow the discussion and send questions to the NSIS meeting via instant messages. 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. What I need to know is, is anyone interested in this? If so, then we'll need someone (in the meeting itself) to act as a moderator. So, please let me know if you are interested in participating this way. Also, if someone wants to volunteer to moderate, that would be great to know as well. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 06:30: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 GAA13369 for ; Fri, 8 Nov 2002 06:30:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8BWMZ15899 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 06:32: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 gA8BWKv15888; Fri, 8 Nov 2002 06:32: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 gA8BVmv15846 for ; Fri, 8 Nov 2002 06:31:48 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13335 for ; Fri, 8 Nov 2002 06:29:16 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gA8BVjU23671; Fri, 8 Nov 2002 12:31:46 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gA8BVjB28050; Fri, 8 Nov 2002 12:31:45 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Geib, Ruediger" Cc: Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Date: Fri, 8 Nov 2002 12:32:52 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi ruediger if the relay is nsis aware then it terminates security. to forward signaling messages to another node it again has to provide security processing. hence it acts a regular nsis node. whether it actually performs for example qos reservation is not relevant for nsis. ciao hannes > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: Friday, November 08, 2002 9:38 AM > To: Hannes.Tschofenig@siemens.com > Cc: nsis@ietf.org > Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of > signaling messages > > > Hello Hannes > > > for example: > > if the only purpose of the relay is to forward the message without > > processing nsis specific parts then there is no reason to > > have this entity as a nsis node. if the relay might even > > modify the message then there is no > > reason why not to treat it as a regular nsis entity. > > My ideas: > The relay should be NSIS aware. It discovers NSIS CSTP neighbors. > It forwards messages there. This may, but doesn't have to include > a change in the next hop address. It has to be able to support all > functions required to keep alive CSTP signaling relations to its > neighbors (i.e. some operational features). > The relay is not involved into any service management. > > Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 06:35: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 GAA13453 for ; Fri, 8 Nov 2002 06:35:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8BbAX16426 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 06:37:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8Bb7v16370; Fri, 8 Nov 2002 06:37: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 gA8Bafv16090 for ; Fri, 8 Nov 2002 06:36:41 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13429 for ; Fri, 8 Nov 2002 06:34:09 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Nov 2002 11:36:38 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA6AA@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Hannes.Tschofenig@siemens.com'" , "Geib, Ruediger" Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 4: Confidentiality of signaling messages Date: Fri, 8 Nov 2002 11:36:38 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi, > hi ruediger > > if the relay is nsis aware then it terminates security. to > forward signaling > messages to another node it again has to provide security > processing. hence > it acts a regular nsis node. whether it actually performs for > example qos > reservation is not relevant for nsis. or at least, not relevant to the NTLP (I think). r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 07:20: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 HAA14317 for ; Fri, 8 Nov 2002 07:20:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8CM7P18872 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 07:22: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 gA8CM5v18861; Fri, 8 Nov 2002 07:22: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 gA8CLNv18822 for ; Fri, 8 Nov 2002 07:21:23 -0500 Received: from fw11.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14284 for ; Fri, 8 Nov 2002 07:18:50 -0500 (EST) Received: by fw11.telekom.de; (8.8.8/1.3/10May95) id NAA00947; Fri, 8 Nov 2002 13:17:37 +0100 (MET) Received: from g8pbr.blf01.telekom.de by G8PXB.blf01.telekom.de with ESMTP; Fri, 8 Nov 2002 11:45:51 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Nov 2002 11:45:51 +0100 Message-Id: From: "Geib, Ruediger" To: Hannes.Tschofenig@siemens.com Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Fri, 8 Nov 2002 11:45:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA8CLNv18823 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello Hannes, comments are in line. Re-ordered things a little, important stuff first. Regards, Rüdiger > > Rüdiger: > > I think the care-of address will do. As I've explained > > in another message, I'd expect signaling with complete > > flow ID should the latter change. That will solve the > > mobility problem. > [hannes] i am not sure to which mail you are referring. in > any case i have the strong feeling that you need to have > some sort of session / reservation > identifier which is not subject to change. if you also want > to change this identifier then you need to update it > along the entire path. maybe i do not catch your point. Rüdiger: Good point. Non ambiguos and not subject to change. It should be based on the home address then. > > Rüdiger: > > The above is valid for sender based reservations. Things > > may look different for receiver based schemes like RSVP > > in combination with mobility. > [hannes] are you sure? both sender and receive can move. i > guess that there is still a need for analysis work. Rüdiger: I'll have to read Michael Thomas draft to get some better understanding. > > Rüdiger: > > In general, I'd regard the so called "flow identifier" as the > > largest possible reservation ID, no matter how it looks like. > [hannes] my point of view is that the reservation (or > session) identifier should be something different > than the flow identifier. if this is not the > case then no such separation is required. Rüdiger: Yes. I wanted to point out that flow ID and reservation ID to some extent serve the same purpose. I however regard the reservation ID as a smarter solution - if it is well defined. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 07:22: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 HAA14375 for ; Fri, 8 Nov 2002 07:22:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8CO5918954 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 07:24:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8CO2v18935; Fri, 8 Nov 2002 07:24: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 gA8CNVv18908 for ; Fri, 8 Nov 2002 07:23:31 -0500 Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14348 for ; Fri, 8 Nov 2002 07:20:58 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA01248; Fri, 8 Nov 2002 13:23:25 +0100 (MET) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA12273; Fri, 8 Nov 2002 13:23:26 +0100 (MET) Received: by MCHH274E with Internet Mail Service (5.5.2656.59) id ; Fri, 8 Nov 2002 13:22:52 +0100 Message-ID: <69EB30B981C8D511AC370002A55CBE27017D4168@MCHH2A4E> From: ICN Genesis Mose To: "'john.loughney@nokia.com'" Cc: Heinrich.Hussmann@inf.tu-dresden.de, nsis@ietf.org Subject: RE: [NSIS] Comment : RSVP Analysis Draft Date: Fri, 8 Nov 2002 13:22:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi, Sure, I would try to come up in some time with some more comments on the draft which might be helpful. in response to some other queries that I got, probably points which were not clear from the first posting: 1. as I am still writing the thesis so unfortunately at the moment no paper is available for further reading. I will be completing the thesis in a month or two and then I can send the work for reading. Till that time you may like to have a look at my thesis talk slides which would give a better idea of the work: http://www-st.inf.tu-dresden.de/home/download/pdf/MasterTalk_SM.pdf 2. there is a typo in the last para of my posting, kindly read it as "end to end QoS" instead of "edge to edge QoS", thanks for pointing out 3. the thesis does study influencing factors like NAT but does not implement a solution, also no security issues are dealt with. These could be topics for further work though. 4. the work could contribute to NSIS, in particular, contributing towards the Internet Draft on RSVP Analysis, and in general for a end to end QoS solution. The point that I wish to put forward is that it might be of interest to use RSVP on access and an diffserv enabled architecture in core (like AQUILA) to provide end to end QoS, instead of coming up with a altogether new protocol. Of course it is debatable. Regards, Sandeep -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Freitag, 8. November 2002 07:56 To: ICN-Genesis.Mose@icn.siemens.de; nsis@ietf.org Cc: Heinrich.Hussmann@inf.tu-dresden.de Subject: RE: [NSIS] Comment : RSVP Analysis Draft Hi, > I am currently doing my Master Thesis at Siemens AG, Munich > under Dresden University of Technology and work focus is QoS > on access networks which is related to the EU project AQUILA > (http://www.ist-aquila.org/). > > The thesis also comes up with a comparison between RSVP, > YESSIR and Boomerang in access network scenarios and in my > study I have come to the conclusion that RSVP in spite of its > complex architecture can still be efficiently used in Access > and some other architecture in the core network, like AQUILA. > Though YESSIR presents a more efficient alternative to RSVP, > but due to it being signaled over RTP, only multimedia > traffic can be guaranteed QoS, and if traffic independent QoS > is required then it does not serve the purpose. Though > Boomerang offers a very efficient architecture but the wide > support of RSVP on routers and OS plays towards its favor. > The major complexity of RSVP starts in the core where the > number of flows increases drastically, but in access where > the flows are limited, it can efficiently be used. > > In the work I make relevant changes to terminate RSVP in the > ingress access and start a AQUILA session on the edge router > for core and then re-start RSVP on egress to complete edge to > edge QoS. In further work I would try to prove that this > solution is better than pure RSVP solution. > I think the work might be of interest to NSIS for further discussion. If you could comment on the current Analysis draft and suggest some text, that would be very helpful. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 08:27: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 IAA18281 for ; Fri, 8 Nov 2002 08:27:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8DTFM24400 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 08:29:15 -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 gA8DTDv24349; Fri, 8 Nov 2002 08: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 gA8DSSv24177 for ; Fri, 8 Nov 2002 08:28:28 -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 IAA18109 for ; Fri, 8 Nov 2002 08:25: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-3.cisco.com (8.12.2/8.12.2) with ESMTP id gA8DSHxF018433; Fri, 8 Nov 2002 05:28:17 -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 AAS55602; Fri, 8 Nov 2002 05:23:41 -0800 (PST) Message-Id: <200211081323.AAS55602@mira-sjc5-4.cisco.com> To: Hannes.Tschofenig@siemens.com cc: "Bob Braden" , nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Key management In-Reply-To: Message from "Hannes Tschofenig" of "Fri, 08 Nov 2002 09:51:40 +0100." Date: Fri, 08 Nov 2002 08:28:23 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > your remark regarding rsvp was not clear to me. in rsvp you select your key > for the integrity object based on an ip address. That's what RSVP does but it needn't be what NSIS does. And again, we'd need to separate out what's done in the application vs. what's done in the transport, but I think it's pretty clear that for an application that expects that it may have a NAT in its path it's undesirable to use an IP address as the basis for identity. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 08:31: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 IAA18397 for ; Fri, 8 Nov 2002 08:31:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8DX6j24696 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 08:33: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 gA8DX4v24689; Fri, 8 Nov 2002 08:33: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 gA8DWpv24637 for ; Fri, 8 Nov 2002 08:32:51 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18361 for ; Fri, 8 Nov 2002 08:30:17 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Nov 2002 13:32:47 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA6B0@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Hannes.Tschofenig@siemens.com'" , nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 5 Req 5.7.10 Hooks ... Date: Fri, 8 Nov 2002 13:32:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all, I think it's right that, as an overall goal, we should aim to be able to have NSIS protocols hook into standardised security solutions developed already. Personally, I still think it should be a SHOULD requirement, to emphasise that a practical security solution implies more than just an objective set of security-specific requirements to be fulfilled. There are three reasons: *) as already pointed out (including, as referenced in another thread, steve bellovin's useipsec draft), rolling our own solution is going to be hard work and not necessarily leading to a good result; *) the appropriate type of technique may be strongly dependent on where in the network and what signalling application we are talking about. Therefore, in any case, we should be looking to avoid hard coding any specific key management protocol into the framework or protocol design. *) from a deployment perspective, we should be aware that administering the identities which are a key part of any key management solution is not a zero cost activity. So, having the ability to re-use existing key management protocols at least opens the door to re-using identity administration which is already being done. Else it's much more likely that people just won't bother at all. There's actually a lot of potential components "out there", certainly more of them (and more widely available) than 5 years ago - even leaving aside PKIs (sometimes useful), there is a whole AAA capability for users including roaming ones, and more recently activities in places like send w.g. and rpsec. We should be looking to be able to exploit all that. cheers, robert h. > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@siemens.com] > Sent: 06 November 2002 10:37 > To: nsis@ietf.org > Subject: [NSIS] Req-Draft: Open Issue 5 Req 5.7.10 Hooks ... > > > hi > > marcus raised the question what todo with this paragraph. > there are the > following options: > > a) drop it (without replacement) > b) replace it by something more concise > c) move it to the framework > > i would like to get an idea what people think about the > possible interaction > between nsis and key management protocols. i personally think that key > management is an important topic and should be addressed in > the requirements > somehow. > > ciao > hannes > > > > -----Original Message----- > > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > > Hannes Tschofenig > > Sent: Monday, November 04, 2002 6:12 PM > > To: brunner@ccrle.nec.de; nsis@ietf.org > > Subject: RE: [NSIS] Req-Draft: Open Issue 5 Req 5.7.10 Hooks ... > > > > > > hi marcus > > > > i think that nsis should be able to interact with other > protocols (called > > hooks in this context). other protocols also require such > interaction. to > > make sure that the interaction is actually possible (and > that it works in > > the expected way) a requirement should be specified. is the > descripion too > > fuzzy? should it simply be discussed in the framework only? > > > > ciao > > hannes > > > > > -----Original Message----- > > > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > > > Marcus Brunner > > > Sent: Friday, November 01, 2002 11:37 PM > > > To: nsis@ietf.org > > > Subject: [NSIS] Req-Draft: Open Issue 5 Req 5.7.10 Hooks ... > > > > > > > > > Req-Draft: Open Issue 5 Req 5.7.10 Hooks ... > > > -------------------------------------------- > > > > > > Proposal to remove req 5.7.10 " Hooks with Authentication and Key > > > Agreement > > > protocols" > > > > > > 5.7.10 Hooks with Authentication and Key Agreement protocols > > > > > > This requirement covers two subsequent steps before a signaling > > > protocol is > > > executed and the required hooks. First there is a need to > agree on a > > > specific authentication protocol. Later this protocol is > executed and > > > provides authentication and establishes the desired security > > > associations. > > > Using these security associations it is then possible to > > exchange secured > > > signaling messages. > > > > > > The signaling protocol implementation SHOULD provide hooks to > > > interact with > > > protocols that allow the negotiation of authentication > and key agreement > > > protocols. Although the negotiation of an authentication and key > > > management > > > protocol within the signaling protocol may be outside the scope > > > it is still > > > required to trigger this exchange in case that no such security > > > association > > > is available. > > > This requirement originates from the fact that more than one key > > > management > > > protocol may be used to provide a security association > for the signaling > > > protocol. Hence the communicating entities must be > capable to agree on a > > > specific authentication. The selected authentication and > key agreement > > > protocol must however be able to create a security association > > > that can be > > > used within the signaling protocol. > > > > > > Key management protocols typically require a larger number of > > messages to > > > be transmitted to allow a session key and the > corresponding security > > > association to be derived. To avoid the complex issue of embedding > > > individual authentication and key agreement protocols > into a specific > > > signaling protocol it is required that most of these protocols > > > are executed > > > independently (prior to the signaling protocol) and > although the key > > > management protocol may be independent there must be a way for the > > > signaling protocol to access and use available (i.e. already > > established) > > > security associations to avoid executing a separate key > > > management protocol > > > (or instance of the same protocol) for protocols that > closely operate > > > together. If no such security association exists then there > > > SHOULD be means > > > for the signaling protocol to dynamically trigger such a protocol. > > > > > > > > > > > > > > > -------------------------------------- > > > Dr. Marcus Brunner > > > Network Laboratories > > > NEC Europe Ltd. > > > > > > E-Mail: brunner@ccrle.nec.de > > > WWW: http://www.ccrle.nec.de/ > > > Phone: +49 (0) 6221 905 11 29 > > > personal home page: http://www.brubers.org/marcus > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 09:31: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 JAA19818 for ; Fri, 8 Nov 2002 09:31:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8EXAi29005 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 09:33:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8EX8v28996; Fri, 8 Nov 2002 09:33: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 gA8EUZv28829 for ; Fri, 8 Nov 2002 09:30:35 -0500 Received: from arb-exchange1.cetaceannetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19699 for ; Fri, 8 Nov 2002 09:28:01 -0500 (EST) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id <445NYMZC>; Fri, 8 Nov 2002 09:20:38 -0500 Message-ID: <6D8664171C38D511B5AD0002B325CE66A9351C@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] Off-site participation at IETF 55 / text conferencing Date: Fri, 8 Nov 2002 09:20:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , John, I definitely would like to take advantage of this opportunity. Ilya -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Friday, November 08, 2002 6:01 AM To: nsis@ietf.org Subject: [NSIS] Off-site participation at IETF 55 / text conferencing Hi all, It seems that there will be an attempt to provide multicast plus instant messaging support for IETF 55. What this means is that folks can follow the discussion and send questions to the NSIS meeting via instant messages. 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. What I need to know is, is anyone interested in this? If so, then we'll need someone (in the meeting itself) to act as a moderator. So, please let me know if you are interested in participating this way. Also, if someone wants to volunteer to moderate, that would be great to know as well. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 09:51: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 JAA20496 for ; Fri, 8 Nov 2002 09:51:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8ErJ130678 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 09:53:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8ErFv30671; Fri, 8 Nov 2002 09:53: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 gA8Eqlv30653 for ; Fri, 8 Nov 2002 09:52:47 -0500 Received: from arb-exchange1.cetaceannetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20488 for ; Fri, 8 Nov 2002 09:50:14 -0500 (EST) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id <445NYM6B>; Fri, 8 Nov 2002 09:42:49 -0500 Message-ID: <6D8664171C38D511B5AD0002B325CE66A9351E@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'Hancock, Robert'" , Bob Braden , nsis@ietf.org, brunner@ccrle.nec.de Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Fri, 8 Nov 2002 09:42:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , My comments in-line Regards, Ilya -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: Thursday, November 07, 2002 5:37 PM To: Bob Braden; nsis@ietf.org; brunner@ccrle.nec.de Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Hi, A comment on scope/layering of this reservation identifier thing (if it ever exists): > *> So reformulating the requirement into "An NSIS protocol > MUST support a > *> reservation identifer" would solve the first one. > > OK, although I would say "MUST be able to support". > > BTW, a reservation identifier is presumably a multi-hop > thing, so in my > 2-level model it is a creature of ULSP, i.e., it is carried in an > SAPU. That's good, because non-QoS signaling applications probably > don't have any reservations to identify. I think we need to work through this. 1. As Marcus has said, we are signalling to set up something, and that something is what we want to identify to be able to manipulate - it doesn't matter if it's QoS (and called a reservation) or something else. [IF] That is right to the point. I just want to add that that something is separate from the flow but used by the flow. The main value of the reservation ID in my mind is to enable referencing that something independently from any other characteristics of the flow. The v6 flow label draft calls this something 'flow state' so this identifier could be a "flow state id". Would that be a better term? [IF] I don't think. See the argument above. 2. My feeling is that this XXX-id would be useful for general signalling applications (i.e. if you use the signalling application in a mobile enviroment, efficiently moving the state is something you want to do anyway). Also, providing the facility might be tricky, and might require subtle interworking with other protocols (e.g. mobility ones). In that case, it be better to provide it as a generic service rather than solving the problem for each signalling application. [IF] Agreed. 3. So, wouldn't one want it within the NTLP (lower layer)? [IF] Absolutely. 4. Or, should we be thinking of some kind of 'core' NSLP toolkit which has these generic facilities? [IF] I think it is good way to move forward. Cheers, Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 10:22: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 KAA22131 for ; Fri, 8 Nov 2002 10:22:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8FONq01108 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 10:24:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8FOBv01091; Fri, 8 Nov 2002 10:24: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 gA8FNUv01043 for ; Fri, 8 Nov 2002 10:23:30 -0500 Received: from infres.enst.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22017 for ; Fri, 8 Nov 2002 10:20:56 -0500 (EST) Received: from enst.fr (dragon.enst.fr [137.194.192.44]) by infres.enst.fr (Postfix) with ESMTP id 680FA190F for ; Fri, 8 Nov 2002 16:23:24 +0100 (MET) Message-ID: <3DCBD73A.E849C8E9@enst.fr> Date: Fri, 08 Nov 2002 16:24:42 +0100 From: Nguyen Thi Mai Trang Organization: ENST - INFRES X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Cc: nsis@ietf.org References: <6D8664171C38D511B5AD0002B325CE66A9351E@mail.cetaceannetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] sender-/receiver-initiated Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, In the draft-ietf-nsis-req-05.txt, the definition of sender-/receiver initiated signaling protocol (page 4) is not clear for me. In fact, the word "inititated" means "initiate the signaling process" or "initiate the reservation"? Are the "sender" and "receiver" considered over the data stream? I take RSVP for example: For a data stream from A to B (source = A, destination = B), A initiates the signaling process by sending PATH message. B initiates the reservation process by sending RESV message. In comparison with sender-initiated definition in the draft, B initiates the reservation, then RSVP is receiver-initiated signaling protocol. In comparison with sender-initiated definition in the draft, A initiates the signaling, then RSVP is sender-initiated signaling protocol. Therefore, RSVP is both sender- and receiver-initiated protocol !??? Another question, what does "the triggering instance" means in the sentence "However, the triggering instance is not specified" ? Thanks for any clarification, Mai Trang _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 11:35: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 LAA26129 for ; Fri, 8 Nov 2002 11:35:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8GbNL08796 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 11:37:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8GbLv08754; Fri, 8 Nov 2002 11:37: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 gA8Ga4v08151 for ; Fri, 8 Nov 2002 11:36:04 -0500 Received: from thoth.sbs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26073 for ; Fri, 8 Nov 2002 11:33:30 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id gA8GZxg00840; Fri, 8 Nov 2002 17:35:59 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gA8GZwB09228; Fri, 8 Nov 2002 17:35:58 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Melinda Shore" Cc: "Bob Braden" , Subject: RE: [NSIS] Key management Date: Fri, 8 Nov 2002 17:37:04 +0100 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 In-Reply-To: <200211081323.AAS55602@mira-sjc5-4.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi melinda! > > your remark regarding rsvp was not clear to me. in rsvp you > select your key > > for the integrity object based on an ip address. > > That's what RSVP does but it needn't be what NSIS does. this is certainly a good point. > And again, we'd need to separate out what's done in the > application vs. what's done in the transport, but I think > it's pretty clear that for an application that expects that > it may have a NAT in its path it's undesirable to use an IP > address as the basis for identity. true. whenever possible one should avoid using ip addresses as identities. ciao hannes > > Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 12:12: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 MAA28831 for ; Fri, 8 Nov 2002 12:12:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8HElG12215 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 12:14: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 gA8HEiv12190; Fri, 8 Nov 2002 12:14: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 gA8H8xv11348 for ; Fri, 8 Nov 2002 12:08:59 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28268 for ; Fri, 8 Nov 2002 12:06:25 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA8H8sa06043; Fri, 8 Nov 2002 09:08:54 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id RAA06386; Fri, 8 Nov 2002 17:08:54 GMT Date: Fri, 8 Nov 2002 17:08:54 GMT Message-Id: <200211081708.RAA06386@gra.isi.edu> To: braden@ISI.EDU, mat@cisco.com Subject: Re: [NSIS] Key management Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> > *> > It turned out that IPsec as currently defined was not directly *> > applicable to the hop/hop case. It seemed quite possible to define a *> > third form of IPsec for this purpose, but the security folks were not *> > particularly interested in helping the QoS folks with their problem. *> > As a result, the RSVP WG was forced to roll their own (RFC 2747). *> > Maybe that decision can/should be revisited in NSIS. *> *> FYI, Steve Bellovin just published a draft *> *-useipsec-00.txt which is probably relevant to *> this. Do you happen to recall the reasons why *> there was pushback? I suspect I know, but it *> would be good to hear it. *> *> Mike *> Mike, I turned to Bob Lindell, who does not suffer from my senior moments. Here is his summary: This is just off the top of my head. I'll think about it some more. 1) IPSEC bases security associations on the IP dst address. RSVP had security associations with the next RSVP capable router along the path. 2) IPSEC did not adequately support multicast at the time (i.e. a security association based on a logical (group) destination address, rather than a physical unicast destination address). Bob This sounds right to me, too. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 12:23: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 MAA29763 for ; Fri, 8 Nov 2002 12:23:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8HPCL13074 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 12:25: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 gA8HPAv13066; Fri, 8 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 gA8HOUv13022 for ; Fri, 8 Nov 2002 12:24:30 -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 MAA29679 for ; Fri, 8 Nov 2002 12:21:56 -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 gA8HOHxF012928; Fri, 8 Nov 2002 09:24:17 -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 AAS62289; Fri, 8 Nov 2002 09:19:39 -0800 (PST) Message-Id: <200211081719.AAS62289@mira-sjc5-4.cisco.com> To: Bob Braden cc: mat@cisco.com, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Key management In-Reply-To: Message from Bob Braden of "Fri, 08 Nov 2002 17:08:54 GMT." <200211081708.RAA06386@gra.isi.edu> Date: Fri, 08 Nov 2002 12:24:21 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > 1) IPSEC bases security associations on the IP dst address. RSVP had > security associations with the next RSVP capable router along the path. That still leaves the possibility of establishing IPSec SAs between individual routers rather than end-to-end. We've been talking about doing hop-by-hop security anyway. Still, among the things that we need to consider is that for the NSIS application (or whatever we're calling it today) that needs security services across hops (end-to-end or end-to-middle) this effectively means that the transport layer isn't really secure since some devices that are along the path but not participating may be decrypting and re-encrypting (or verifying and re-authenticating) messages in the transport layer, and they can peer into packet contents, or change them. > 2) IPSEC did not adequately support multicast at the time (i.e. a > security association based on a logical (group) destination address, > rather than a physical unicast destination address). This is still more-or-less true; the msec working group is hard at work but I don't think they've gotten any documents into WG last call yet. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 12:47: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 MAA01940 for ; Fri, 8 Nov 2002 12:47:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8HnXG14780 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 12:49: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 gA8HnVv14773; Fri, 8 Nov 2002 12:49: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 gA8Hmsv14723 for ; Fri, 8 Nov 2002 12:48:54 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01862 for ; Fri, 8 Nov 2002 12:46:19 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA8Hmna28608; Fri, 8 Nov 2002 09:48:49 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id RAA06453; Fri, 8 Nov 2002 17:48:49 GMT Date: Fri, 8 Nov 2002 17:48:49 GMT Message-Id: <200211081748.RAA06453@gra.isi.edu> To: braden@ISI.EDU, mshore@cisco.com Subject: Re: [NSIS] Key management Cc: mat@cisco.com, nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> From mshore@cisco.com Fri Nov 8 09:24:37 2002 *> To: Bob Braden *> cc: mat@cisco.com, nsis@ietf.org *> From: Melinda Shore *> Subject: Re: [NSIS] Key management *> Date: Fri, 08 Nov 2002 12:24:21 -0500 *> X-AntiVirus: scanned by AMaViS 0.2.1 *> *> > 1) IPSEC bases security associations on the IP dst address. RSVP had *> > security associations with the next RSVP capable router along the path. *> *> That still leaves the possibility of establishing IPSec SAs *> between individual routers rather than end-to-end. We've *> been talking about doing hop-by-hop security anyway. *> Melinda, (Believe me, the RSVP WG really did NOT want to invent any new security mechanism, and we tried hard to use IPsec. but...) No, that doesn't help. A Path message still has the session address as its IP destination address, not the next hop address, and that is what IPsec looks at. *> Still, among the things that we need to consider is that for *> the NSIS application (or whatever we're calling it today) *> that needs security services across hops (end-to-end or *> end-to-middle) this effectively means that the transport *> layer isn't really secure since some devices that are along *> the path but not participating may be decrypting and *> re-encrypting (or verifying and re-authenticating) messages *> in the transport layer, and they can peer into packet *> contents, or change them. I don't understand. Devices along the path are either NSIS-trusted and have keys for NSIS neighbors, or they aren't. Maybe you are pointing out the inherent insecurity of the transitive trust model, that worries the security folks? Sorry if I am missing something. Bob *> *> > 2) IPSEC did not adequately support multicast at the time (i.e. a *> > security association based on a logical (group) destination address, *> > rather than a physical unicast destination address). *> *> This is still more-or-less true; the msec working group is *> hard at work but I don't think they've gotten any documents *> into WG last call yet. *> *> Melinda *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 13:10: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 NAA03804 for ; Fri, 8 Nov 2002 13:10:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8IC7o17235 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 13:12: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 gA8IC4v17191; Fri, 8 Nov 2002 13:12: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 gA8I7ov17014 for ; Fri, 8 Nov 2002 13:07:50 -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 NAA03526 for ; Fri, 8 Nov 2002 13:05:14 -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 gA8I7axF014799; Fri, 8 Nov 2002 10:07:36 -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 AAS64421; Fri, 8 Nov 2002 10:03:01 -0800 (PST) Message-Id: <200211081803.AAS64421@mira-sjc5-4.cisco.com> To: Bob Braden cc: mat@cisco.com, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Key management In-Reply-To: Message from Bob Braden of "Fri, 08 Nov 2002 17:48:49 GMT." <200211081748.RAA06453@gra.isi.edu> Date: Fri, 08 Nov 2002 13:07:43 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > No, that doesn't help. A Path message still has the session address as > its IP destination address, not the next hop address, and that is what > IPsec looks at. Right, but I thought the addressing model is still open. I prefer end-to-end addressing myself, but in the new IETF spirit of including security in protocol gestalt perhaps this problem might have some bearing on overall protocol design. > I don't understand. Devices along the path are either NSIS-trusted > and have keys for NSIS neighbors, or they aren't. Maybe you are > pointing out the inherent insecurity of the transitive trust model, > that worries the security folks? Sorry if I am missing something. Transitivity may work for identity authentication but I'm less comfortable with it for things like confidentiality. That is to say, identity (are you are who you say you are?) is a yes/no question, assuming that you have a high degree of confidence in the authentication mechanism in every hop along the path. I think that when things like access policy are involved the question becomes stickier. Let's say that I've got two NATs in the path and they belong to two different administrative domains (they have independent administrative policies). If we rely on hop-by-hop security, the first NAT in the path (with respect to the sender) is going to get a copy of the second NAT's keying material, assuming that we use some sort of key exchange rather than either using pre-shared keys or doing some sort of public-key based key exchange at this layer, as well, which can be quite costly. Whether or not you trust that first NAT with the second NAT's keys is going to be a matter of policy, and while the question of provable identity isn't orthogonal to that question it's at least at a slight tilt. But again, I think this is a problem for the application, not the transport. The transport needs to protect itself against forgeries, theft of service, etc., and I don't think it's necessarily the job of the NSIS transport to protect the NSIS application. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 13:21: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 NAA04577 for ; Fri, 8 Nov 2002 13:21:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8IN8V17873 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 13:23: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 gA8IN6v17836; Fri, 8 Nov 2002 13:23: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 gA8IMGv17740 for ; Fri, 8 Nov 2002 13:22:16 -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 NAA04364 for ; Fri, 8 Nov 2002 13:19:40 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gA8IMAot008203; Fri, 8 Nov 2002 10:22:10 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAN77244; Fri, 8 Nov 2002 10:16:24 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA14355; Fri, 8 Nov 2002 10:22:08 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15820.208.279869.225858@thomasm-u1.cisco.com> Date: Fri, 8 Nov 2002 10:22:08 -0800 (PST) To: Melinda Shore Cc: Bob Braden , mat@cisco.com, nsis@ietf.org Subject: Re: [NSIS] Key management In-Reply-To: <200211081803.AAS64421@mira-sjc5-4.cisco.com> References: <200211081748.RAA06453@gra.isi.edu> <200211081803.AAS64421@mira-sjc5-4.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Melinda Shore writes: > > No, that doesn't help. A Path message still has the session address as > > its IP destination address, not the next hop address, and that is what > > IPsec looks at. > > Right, but I thought the addressing model is still open. I > prefer end-to-end addressing myself, but in the new IETF > spirit of including security in protocol gestalt perhaps > this problem might have some bearing on overall protocol design. #include This is not a small point. One of things my draft went into at some length is the fact that I couldn't figure out what sort of accounting model for lack of a better phrase was intended for policy objects. When the receiver sends RESV's and there are potentially many PEP's in the path, who's responsible for supplying those policy objects? I couldn't find any guidance in RFC 2750. Are they loaded up front by the receiver, or can they be inserted hopwise (sort of a relay model)? The one thing I'm pretty certain of is that cross realm RSVP with policy will probably not work. Also: it's always struck me as odd that it's effectively a "receiver pays" kind of model. I understand *why* it's that way (RSVP is receiver oriented), but it still strike me as odd. Maybe I'm bellheaded and haven't be properly enlightened, but it seems worth considering at least both kinds of "pay" models. Please go easy on me for using hot button words like "pay" and "accounting" etc... I mean them metaphorically... Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 13:26: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 NAA05184 for ; Fri, 8 Nov 2002 13:26:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8IS6418215 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 13:28: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 gA8IS3v18202; Fri, 8 Nov 2002 13:28: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 gA8IRMv18150 for ; Fri, 8 Nov 2002 13:27:22 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05037 for ; Fri, 8 Nov 2002 13:24:47 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA8IRGa21149; Fri, 8 Nov 2002 10:27:17 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id SAA06481; Fri, 8 Nov 2002 18:27:16 GMT Date: Fri, 8 Nov 2002 18:27:16 GMT Message-Id: <200211081827.SAA06481@gra.isi.edu> To: braden@ISI.EDU, mshore@cisco.com Subject: Re: [NSIS] Key management Cc: mat@cisco.com, nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> > No, that doesn't help. A Path message still has the session address as *> > its IP destination address, not the next hop address, and that is what *> > IPsec looks at. *> *> Right, but I thought the addressing model is still open. I *> prefer end-to-end addressing myself, but in the new IETF *> spirit of including security in protocol gestalt perhaps *> this problem might have some bearing on overall protocol design. OK, that's fair. Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 8 13:49: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 NAA07505 for ; Fri, 8 Nov 2002 13:49:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8IpE820816 for nsis-archive@odin.ietf.org; Fri, 8 Nov 2002 13:51: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 gA8IpCv20809; Fri, 8 Nov 2002 13:51: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 gA8Ioev20767 for ; Fri, 8 Nov 2002 13:50:40 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07450 for ; Fri, 8 Nov 2002 13:48:03 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gA8IoXa03520; Fri, 8 Nov 2002 10:50:33 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id SAA06501; Fri, 8 Nov 2002 18:50:33 GMT Date: Fri, 8 Nov 2002 18:50:33 GMT Message-Id: <200211081850.SAA06501@gra.isi.edu> To: mshore@cisco.com, mat@cisco.com Subject: Re: [NSIS] Key management Cc: braden@ISI.EDU, nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> This is not a small point. One of things my draft Agreed. In the end, this is why RSVP today is used in enterprise networking but not in the general Internet. You cannot in general have QoS without some sort of policy pushback, either administrative (in a corporation) or financial (in the Internet). *> went into at some length is the fact that I couldn't *> figure out what sort of accounting model for lack of *> a better phrase was intended for policy objects. When *> the receiver sends RESV's and there are potentially *> many PEP's in the path, who's responsible for supplying *> those policy objects? I couldn't find any guidance in *> RFC 2750. Are they loaded up front by the receiver, *> or can they be inserted hopwise (sort of a relay model)? Policy objects that contain user certificates might be supplied by the entities that initiate the signaling, e.g., the end systems. Or they might be supplied at administrative boundaries, e.g., a corporation might supply the policy object when a reservation crosses the border into the ISP. These alternatives were discussed in papers and documents a few years ago. Shai Herzog, who played a key role in starting the COPS work, wrote and talked about these issues, during his thesis work under Deborah Estrin. However, to make this real requires a set of multilateral agreements on economic and policy models, and there has not been the will to make that happen. There is also an issue of a forum to do this administrative design; the IETF is not really suitable. It would be easier if the Internet, like the phone system, had started as a commercial monopoly and later broke up. *> The one thing I'm pretty certain of is that cross realm *> RSVP with policy will probably not work. I don't see a technical protocol problem, only a problem of agreeing on policies and procedures. *> *> Also: it's always struck me as odd that it's *> effectively a "receiver pays" kind of model. I understand *> *why* it's that way (RSVP is receiver oriented), but it *> still strike me as odd. Maybe I'm bellheaded and haven't The receiver-pays model was suited to support video broadcasting in the Internet. It also has scalability advantages, for large multicast groups. However, I believe that RSVP was actually agnostic about this; the payment could be based on Policy objects carried downstream in Path mesasges, giving a sender-pays model. *> be properly enlightened, but it seems worth considering *> at least both kinds of "pay" models. *> *> Please go easy on me for using hot button words *> like "pay" and "accounting" etc... I mean them *> metaphorically... *> *> Mike *> No, au contraire, pay and accounting are inseparable from QoS. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Nov 9 00:57: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 AAA02813 for ; Sat, 9 Nov 2002 00:57:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA95xXg29267 for nsis-archive@odin.ietf.org; Sat, 9 Nov 2002 00:59: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 gA95xUv29260; Sat, 9 Nov 2002 00:59:30 -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 gA95wmv29220 for ; Sat, 9 Nov 2002 00:58:48 -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 AAA02793 for ; Sat, 9 Nov 2002 00:56:07 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gA95wSaE027489; Fri, 8 Nov 2002 21:58:28 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAN94358; Fri, 8 Nov 2002 21:52:52 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id VAA14411; Fri, 8 Nov 2002 21:58:36 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15820.41993.361955.805653@thomasm-u1.cisco.com> Date: Fri, 8 Nov 2002 21:58:33 -0800 (PST) To: Bob Braden Cc: mat@cisco.com, nsis@ietf.org Subject: Re: [NSIS] Key management In-Reply-To: <200211081708.RAA06386@gra.isi.edu> References: <200211081708.RAA06386@gra.isi.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bob Braden writes: > *> > > *> > It turned out that IPsec as currently defined was not directly > *> > applicable to the hop/hop case. It seemed quite possible to define a > *> > third form of IPsec for this purpose, but the security folks were not > *> > particularly interested in helping the QoS folks with their problem. > *> > As a result, the RSVP WG was forced to roll their own (RFC 2747). > *> > Maybe that decision can/should be revisited in NSIS. > *> > *> FYI, Steve Bellovin just published a draft > *> *-useipsec-00.txt which is probably relevant to > *> this. Do you happen to recall the reasons why > *> there was pushback? I suspect I know, but it > *> would be good to hear it. > *> > *> Mike > *> > > Mike, > > I turned to Bob Lindell, who does not suffer from my senior moments. > Here is his summary: > > > This is just off the top of my head. I'll think about it some more. > > 1) IPSEC bases security associations on the IP dst address. RSVP had > security associations with the next RSVP capable router along the path. > > 2) IPSEC did not adequately support multicast at the time (i.e. a > security association based on a logical (group) destination address, > rather than a physical unicast destination address). At the risk of putting my foot in my mouth (again!), this doesn't make very much sense for hop-by-hop kinds of security. As I think Melinda pointed out, IPsec is obviously a non-starter for anything which requires getting something to and from the two RSVP hosts, but I don't see how these comments are applicable. for hop-by-hop. For (1), I'd think that it would just be a transport mode SA to the next hop, and for (2), although the DST address is a multicast address RFC 2401 supports that for selectors, and I don't think this implies that you need group keying between the next hops... So, I'm still lost. Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Nov 9 23:50: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 XAA01113 for ; Sat, 9 Nov 2002 23:50:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAA4r3802318 for nsis-archive@odin.ietf.org; Sat, 9 Nov 2002 23:53: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 gAA4r1v02310; Sat, 9 Nov 2002 23:53: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 gA8Ifuv19816 for ; Fri, 8 Nov 2002 13:41:56 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06349; Fri, 8 Nov 2002 13:39:20 -0500 (EST) Message-Id: <200211081839.NAA06349@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 08 Nov 2002 13:39:19 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-fw-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling 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 Next Steps in Signaling Working Group of the IETF. Title : Next Steps in Signaling: Framework Author(s) : I. Freytsis, R. Hancock Filename : draft-ietf-nsis-fw-01.txt Pages : 53 Date : 2002-11-8 The NSIS working group is considering protocols for signaling for resources for a traffic flow along its path in the network. The requirements for such signaling are being developed in [2]; this Internet Draft will propose a framework for such signaling. This initial version provides a model of the entities that take part in the signaling. It discusses the considerations that must be taken into account in developing the framework, particularly the structural options for the structure of such a protocol, and the interactions between NSIS and other protocols and functions, including security issues. Finally, it includes background material on how NSIS could support particular signaling applications. It is expected that future versions of this document will distill these structural options into a concrete technical framework, and material on particular signaling applications and deployment scenarios will be moved into separate NSIS applicability statements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-fw-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-fw-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-8124914.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-fw-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-fw-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-8124914.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Nov 10 16:51: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 QAA24611 for ; Sun, 10 Nov 2002 16:51:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAALs3X24381 for nsis-archive@odin.ietf.org; Sun, 10 Nov 2002 16:54: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 gAALrxv24350; Sun, 10 Nov 2002 16:54: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 gAALqxv24324 for ; Sun, 10 Nov 2002 16:52:59 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24583 for ; Sun, 10 Nov 2002 16:50:20 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 10 Nov 2002 21:52:52 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5DC0@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Melinda Shore , nsis@ietf.org Date: Sun, 10 Nov 2002 21:52:49 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] NSIS routing issues (was: RE: Comments on framework draft) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi Melinda, you raised some routing related issues in your first round of framework comments. > 4.1 Feel quite strongly that interface selection should be > handled by IP routing > > 4.5.1 Why do you want to identify "flows" at the NSIS > protocol layer? The text doesn't make a good case for > it. This belongs in the application > > 5.2 Some of this would fall under the rubric "policy > routing," which could be mentioned > I think there are a number of inter-related issues here. If by 'policy routing' you mean 'making a packet forwarding decision based on something in addition to the IP DA' [*], I agree this is the main point at issue in the first half of 5.2. The existence of policy routing of this type presents a set of very hard (possibly insoluble) problems for NSIS-like path-coupled signalling (not all of which are captured in the framework document so far). I'd be very interested to hear some feedback about how common this is in the real world, and what is actually used other than the IP DA in forwarding lookups. It's the same reason behind some of the text in 4.1 which you may be referring to. Actually, I think there's no room for disagreement here (or rather, disagreement should be about the more fundamental issue of the addressing model): peer-peer addressed signalling messages will be normally routed, end2end addressed signalling messages will be routed the same way as data traffic would be (which might include policy routing for example). If you think the current text says more (or less) than this, feel free to suggest modification. So far as 4.5.1 is concerned, the motivation is 2-fold: 1. Nodes may need to do 'standardised' message processing which is independent of any application (e.g. a NAT or SIIT box), so we shouldn't hide the corresponding packet header information inside the application. 2. Because of policy routing, the IP DA alone doesn't define the path, you need this flow identification information as well. If the NTLP is responsible for keeping the signalling on the path, it needs access to this data. [The other use of the flow identification - to say what packets you actually want to do something to - obviously only needs to live in the application; maybe there are two levels of flow identification needed.] (1) could possibly be handled by Bob's proposed 'generic core application', but (2) seems to me to be very much an NTLP issue. In any case, it's another layer-interface issue to add to the list. Hope this has all been meaningful, Cheers, Robert H. [*] I've also seen the term 'policy routing' used to refer to filtering routing protocol (typically BGP) messages according to some policy rules. I don't think we care about this at all in NSIS, provided the resulting forwarding tables are simply DA based. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Nov 10 16:51: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 QAA24624 for ; Sun, 10 Nov 2002 16:51:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAALs4C24402 for nsis-archive@odin.ietf.org; Sun, 10 Nov 2002 16:54: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 gAALs2v24367; Sun, 10 Nov 2002 16:54: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 gAALr2v24332 for ; Sun, 10 Nov 2002 16:53:02 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24587 for ; Sun, 10 Nov 2002 16:50:23 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 10 Nov 2002 21:52:55 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5DC2@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Michael Thomas , Bob Braden Cc: nsis@ietf.org Subject: RE: [NSIS] Key management Date: Sun, 10 Nov 2002 21:52:53 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all, I think there's a more basic question here than simply 'can we use IPsec for NSIS?'. If we look at the whole army of available security mechanisms, there are two broad categories: a) ones which do authentication (and key management) by a bidirectional exchange between a stable pair of endpoints (e.g. a TLS session, IPsec SA, EAP exchange...) b) ones which rely on a PKI or pre-configured shared keys (or a third party key server) and allow single-shot secure message sending (s/mime and so on), even without knowing the precise identity of the peer you are talking to. These methods are generally either less efficient or less scalable (or both). On the other hand, the signalling we are talking about in NSIS unavoidably has a component which can only be handled under (b) [path-like messages, especially after a route change and/or sent over an nsis-unaware cloud], but IMHO (b) isn't appropriate to handling all of nsis' security needs. Using techniques from category (a) probably imply building non-trivial association between peers. I'm well aware that this summary is outrageously abbreviated, but I find it easier to start simple: how much should we tune the structure of NSIS to make securing it easy? cheers, robert h. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: 09 November 2002 05:59 > To: Bob Braden > Cc: mat@cisco.com; nsis@ietf.org > Subject: Re: [NSIS] Key management > > > Bob Braden writes: > > *> > > > *> > It turned out that IPsec as currently defined was > not directly > > *> > applicable to the hop/hop case. It seemed quite > possible to define a > > *> > third form of IPsec for this purpose, but the > security folks were not > > *> > particularly interested in helping the QoS folks > with their problem. > > *> > As a result, the RSVP WG was forced to roll their > own (RFC 2747). > > *> > Maybe that decision can/should be revisited in NSIS. > > *> > > *> FYI, Steve Bellovin just published a draft > > *> *-useipsec-00.txt which is probably relevant to > > *> this. Do you happen to recall the reasons why > > *> there was pushback? I suspect I know, but it > > *> would be good to hear it. > > *> > > *> Mike > > *> > > > > Mike, > > > > I turned to Bob Lindell, who does not suffer from my > senior moments. > > Here is his summary: > > > > > > This is just off the top of my head. I'll think about > it some more. > > > > 1) IPSEC bases security associations on the IP dst > address. RSVP had > > security associations with the next RSVP capable router > along the path. > > > > 2) IPSEC did not adequately support multicast at the > time (i.e. a > > security association based on a logical (group) > destination address, > > rather than a physical unicast destination address). > > At the risk of putting my foot in my mouth (again!), > this doesn't make very much sense for hop-by-hop > kinds of security. As I think Melinda pointed > out, IPsec is obviously a non-starter for > anything which requires getting something to > and from the two RSVP hosts, but I don't see > how these comments are applicable. for > hop-by-hop. For (1), I'd think that it would > just be a transport mode SA to the next hop, > and for (2), although the DST address is a > multicast address RFC 2401 supports that for > selectors, and I don't think this implies that > you need group keying between the next hops... > > So, I'm still lost. > > Mike > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Nov 10 16:51: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 QAA24637 for ; Sun, 10 Nov 2002 16:51:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAALs5824414 for nsis-archive@odin.ietf.org; Sun, 10 Nov 2002 16:54:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAALs3v24395; Sun, 10 Nov 2002 16:54: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 gAALr2v24334 for ; Sun, 10 Nov 2002 16:53:02 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24588 for ; Sun, 10 Nov 2002 16:50:23 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 10 Nov 2002 21:52:55 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5DC1@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Bob Braden , nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Sun, 10 Nov 2002 21:52:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Bob, > Robert, > > The architectural principle in CSTP is that it operates hop/hop. > This turns out to capture a lot of generic functionality, which is > its benefit. That does not mean that all generic > functionality belongs > in CSTP, particularly generic E2E functionality. > > So I can see several alternatives: > > (1) Overload CSTP (I mean overload in the technical sense, not the > pejorative sense) by putting any important generic > functionality in CSTP. This effectively gives the CSTP level a > second major architectural task, in addition to handling > hop/hop transport. The effect on the spec would be to add > calls to the API for the library of generic functionsI. > > Note that my latest draft suggests doing exactly this for the > interface to routing, which is probably of importance to both > levels. However, I think that is a somewhat different case, > since routing is really a hop/hop issue although it has to > be available to the ULSP. > > (2) Create some additional structure in the upper level, for example a > library of common generic functions. > > I suggest that (2) is architecturally preferable, for the following > reason. We may expect that over time additional generic > functions will > be defined and some will be modified, as the IETF develops different > ULSPs. But you really don't want to decouple these changes from the [reh] did you want that ^^^^^? > API to the CSTP, which you want to be as stable as possible. > > Hope this helps, > > Bob Braden > [reh] I see the reasoning here; the final answer to the question seems quite unclear to me at the moment. (Part of the issue is the name: 'reservation id' should refer to something which an application wants shifted around, whereas we could also talk about maintaining a 'logical path' with this identifier, which took all upper layer state around with it. One question is whether the functionality of this identifier only needs support at specific application aware nodes, or whether e.g. in a mobile network it should be specially supported in an application-neutral way.) I also noted your draft raises the question of whether we should develop a (using non-judgmental terminology) NTLP API, and I can see the value of that too. When do you think it would be the right time to start doing this? Cheers, Robert PS. FWIW the framework slot in Atlanta will probably concentrate on this 'inter-layer' issue. Please send opinions (that's a general invitation, by the way.) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Nov 10 17:05: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 RAA25289 for ; Sun, 10 Nov 2002 17:05:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAAM79M25543 for nsis-archive@odin.ietf.org; Sun, 10 Nov 2002 17:07:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAAM77v25488; Sun, 10 Nov 2002 17:07: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 gAAM6pv25206 for ; Sun, 10 Nov 2002 17:06:51 -0500 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25286 for ; Sun, 10 Nov 2002 17:04:13 -0500 (EST) Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id gAAM6fm19741; Sun, 10 Nov 2002 14:06:41 -0800 (PST) Date: Sun, 10 Nov 2002 14:06:41 -0800 (PST) From: Bob Braden Message-Id: <200211102206.gAAM6fm19741@boreas.isi.edu> To: braden@ISI.EDU, nsis@ietf.org, robert.hancock@roke.co.uk Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> > (2) Create some additional structure in the upper level, for example a *> > library of common generic functions. *> > *> > I suggest that (2) is architecturally preferable, for the following *> > reason. We may expect that over time additional generic *> > functions will *> > be defined and some will be modified, as the IETF develops different *> > ULSPs. But you really don't want to decouple these changes from the *> [reh] did you want that ^^^^^? Robert, Ooops! No, I didn't!!! Thanks for catching that. *> > API to the CSTP, which you want to be as stable as possible. *> > *> > Hope this helps, *> > *> > Bob Braden *> > *> [reh] I see the reasoning here; the final answer to the question seems quite unclear to me at the moment. *> *> (Part of the issue is the name: 'reservation id' should refer to something which an application wants shifted around, whereas we could also talk about maintaining a 'logical path' with this identifier, which took all upper layer state Logical path? I don't get how that relates to the real path that is determined by IP routing. Also, the reservation ID corresponds roughly to what RSVP called a session, and it includes port information as well as path information. I think we are talking about different abstractions. around with it. One question is whether the functionality of this identifier o nly needs support at specific application aware nodes, or whether e.g. in a mobile network it should be specially supported in an application-neutral way.) *> *> I also noted your draft raises the question of whether we should develop a (using non-judgmental terminology) NTLP API, and I can see the value of that too. When do you think it would be the right time to start doing this? As I indicated, I think this is a decision for the WG. However, I can see some advantage to first developing the 2-layer model using a generic API; in this process the generic API will no doubt evolve. Then when it seems that the generic API has become stable, define a real API. (However, the decision might be driven by market forces.) Bob *> *> Cheers, *> *> Robert *> *> PS. FWIW the framework slot in Atlanta will probably concentrate on this 'inter-layer' issue. Please send opinions (that's a general invitation, by the way.) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Nov 10 17:11: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 RAA25369 for ; Sun, 10 Nov 2002 17:11:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAAME7E25931 for nsis-archive@odin.ietf.org; Sun, 10 Nov 2002 17:14: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 gAAME4v25922; Sun, 10 Nov 2002 17:14: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 gAAMD1v25901 for ; Sun, 10 Nov 2002 17:13:01 -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 RAA25355 for ; Sun, 10 Nov 2002 17:10:22 -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 gAAMCjaE027347; Sun, 10 Nov 2002 14:12:45 -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 AAT05855; Sun, 10 Nov 2002 14:08:12 -0800 (PST) Message-Id: <200211102208.AAT05855@mira-sjc5-4.cisco.com> To: "Hancock, Robert" cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Key management In-Reply-To: Message from "Hancock, Robert" of "Sun, 10 Nov 2002 21:52:53 GMT." <76C92FBBFB58D411AE760090271ED41805DF5DC2@rsys002a.roke.co.uk> Date: Sun, 10 Nov 2002 17:12:48 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > I'm well aware that this summary is outrageously > abbreviated, but I find it easier to start simple: how > much should we tune the structure of NSIS to make securing > it easy? I have to admit that I don't understand this message very well. Starting from mechanism is generally a bad idea (and I have some quibbles about your dichotomy, but that's another matter). The place to start is with understanding the threats (attacks) against the framework, which is where Hannes' work becomes highly useful. What sort of keying infrastructure you use is going to depend on the problem you're trying to solve - do you have a handful of nodes participating or thousands? Are they in the same administrative domain or not? Etc. Melinda p.s. As an aside, we have to be careful about specifying what we mean when we talk about "scalability." A PKI will scale in the number of nodes it supports but public key operations are computationally expensive. The use of pre-shared keys can reduce the number of messages required to authenticate and is less computationally expensive, but it doesn't scale administratively, etc. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Nov 10 19:54: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 TAA27656 for ; Sun, 10 Nov 2002 19:54:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAB0uit32095 for nsis-archive@odin.ietf.org; Sun, 10 Nov 2002 19:56: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 gAB0ugv32080; Sun, 10 Nov 2002 19:56: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 gAB0tTv32036 for ; Sun, 10 Nov 2002 19:55:29 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27593 for ; Sun, 10 Nov 2002 19:52:50 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Nov 2002 00:55:20 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5DCC@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Melinda Shore Cc: nsis@ietf.org Subject: RE: [NSIS] Key management Date: Mon, 11 Nov 2002 00:55:20 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Melinda, My point (poorly expressed maybe) is that the framework is currently still something that could be split up pretty well any way you want, so we can't start with an analysis of the threats against its components. Some criteria are needed to motivate the framework decomposition in the first place: what part should security considerations play? And how should those considerations be expressed? I'd love it if we could stucture the framework any way we liked and then demand it to be securable. But that demand is much more likely to be successful if we make a nod to feasibility at the outset. Cheers, Robert H. PS I believe that the range of security environments we're trying to address is already captured in the requirements, and it is "the lot". Given that we're being discouraged from thinking about fundamentally different basic protocols for different environments, we should be looking for an overall assessment of the impact on the framework decomposition. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: 10 November 2002 22:13 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: [NSIS] Key management > > > > I'm well aware that this summary is outrageously > > abbreviated, but I find it easier to start simple: how > > much should we tune the structure of NSIS to make securing > > it easy? > > I have to admit that I don't understand this message very > well. Starting from mechanism is generally a bad idea (and > I have some quibbles about your dichotomy, but that's > another matter). The place to start is with understanding > the threats (attacks) against the framework, which is where > Hannes' work becomes highly useful. What sort of keying > infrastructure you use is going to depend on the problem > you're trying to solve - do you have a handful of nodes > participating or thousands? Are they in the same > administrative domain or not? Etc. > > Melinda > > p.s. As an aside, we have to be careful about specifying > what we mean when we talk about "scalability." A PKI will > scale in the number of nodes it supports but public key > operations are computationally expensive. The use of > pre-shared keys can reduce the number of messages required > to authenticate and is less computationally expensive, but > it doesn't scale administratively, etc. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Nov 10 22:49: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 WAA00315 for ; Sun, 10 Nov 2002 22:49:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAB3pGG07422 for nsis-archive@odin.ietf.org; Sun, 10 Nov 2002 22:51: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 gAB3pEv07393; Sun, 10 Nov 2002 22:51: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 gAB3Yfv06473 for ; Sun, 10 Nov 2002 22:34:41 -0500 Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00040 for ; Sun, 10 Nov 2002 22:32:00 -0500 (EST) Received: (from braden@localhost) by boreas.isi.edu (8.11.6/8.11.2) id gAB3YRU10021; Sun, 10 Nov 2002 19:34:27 -0800 (PST) Date: Sun, 10 Nov 2002 19:34:27 -0800 (PST) From: Bob Braden Message-Id: <200211110334.gAB3YRU10021@boreas.isi.edu> To: braden@ISI.EDU, mat@cisco.com Subject: Re: [NSIS] Key management Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> At the risk of putting my foot in my mouth (again!), *> this doesn't make very much sense for hop-by-hop *> kinds of security. As I think Melinda pointed *> out, IPsec is obviously a non-starter for *> anything which requires getting something to *> and from the two RSVP hosts, but I don't see *> how these comments are applicable. for *> hop-by-hop. For (1), I'd think that it would *> just be a transport mode SA to the next hop, *> and for (2), although the DST address is a *> multicast address RFC 2401 supports that for *> selectors, and I don't think this implies that *> you need group keying between the next hops... *> *> So, I'm still lost. *> *> Mike *> And I am at a loss for how to explain it more clearly than Bob Lindell already did. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 11 03:16: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 DAA13316 for ; Mon, 11 Nov 2002 03:16:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAB8IeJ27714 for nsis-archive@odin.ietf.org; Mon, 11 Nov 2002 03:18: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 gAB8Icv27705; Mon, 11 Nov 2002 03:18: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 gAB8Hpv27677 for ; Mon, 11 Nov 2002 03:17:51 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13311 for ; Mon, 11 Nov 2002 03:15:08 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id gAB8HeL02965; Mon, 11 Nov 2002 09:17:40 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gAB8HdB28809; Mon, 11 Nov 2002 09:17:39 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Michael Thomas" , "Bob Braden" Cc: Subject: RE: [NSIS] Key management Date: Mon, 11 Nov 2002 09:18:32 +0100 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) In-Reply-To: <15820.41993.361955.805653@thomasm-u1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi mike! i guess the problem pointed out here is that - if you want to secure rsvp traffic in a hop-by-hop fashion then you need to have some traffic selector which knows which ipsec sa to apply. if you however have more than one possible path then you might experience problems when selecting the security association since the ip packet is addressed to the destination and not to the next host (at least for the rsvp path message). ciao hannes > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Michael Thomas > Sent: Saturday, November 09, 2002 6:59 AM > To: Bob Braden > Cc: mat@cisco.com; nsis@ietf.org > Subject: Re: [NSIS] Key management > > > Bob Braden writes: > > *> > > > *> > It turned out that IPsec as currently defined was not directly > > *> > applicable to the hop/hop case. It seemed quite > possible to define a > > *> > third form of IPsec for this purpose, but the security > folks were not > > *> > particularly interested in helping the QoS folks with > their problem. > > *> > As a result, the RSVP WG was forced to roll their own > (RFC 2747). > > *> > Maybe that decision can/should be revisited in NSIS. > > *> > > *> FYI, Steve Bellovin just published a draft > > *> *-useipsec-00.txt which is probably relevant to > > *> this. Do you happen to recall the reasons why > > *> there was pushback? I suspect I know, but it > > *> would be good to hear it. > > *> > > *> Mike > > *> > > > > Mike, > > > > I turned to Bob Lindell, who does not suffer from my senior moments. > > Here is his summary: > > > > > > This is just off the top of my head. I'll think about it some more. > > > > 1) IPSEC bases security associations on the IP dst address. > RSVP had > > security associations with the next RSVP capable router > along the path. > > > > 2) IPSEC did not adequately support multicast at the time (i.e. a > > security association based on a logical (group) destination address, > > rather than a physical unicast destination address). > > At the risk of putting my foot in my mouth (again!), > this doesn't make very much sense for hop-by-hop > kinds of security. As I think Melinda pointed > out, IPsec is obviously a non-starter for > anything which requires getting something to > and from the two RSVP hosts, but I don't see > how these comments are applicable. for > hop-by-hop. For (1), I'd think that it would > just be a transport mode SA to the next hop, > and for (2), although the DST address is a > multicast address RFC 2401 supports that for > selectors, and I don't think this implies that > you need group keying between the next hops... > > So, I'm still lost. > > Mike > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 11 04:12:00 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 EAA13981 for ; Mon, 11 Nov 2002 04:12:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAB9EDM30856 for nsis-archive@odin.ietf.org; Mon, 11 Nov 2002 04:14: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 gAB9EBv30849; Mon, 11 Nov 2002 04:14: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 gAB9D8v30773 for ; Mon, 11 Nov 2002 04:13:08 -0500 Received: from tama5.ecl.ntt.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13948 for ; Mon, 11 Nov 2002 04:10:24 -0500 (EST) Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/21/02) with ESMTP id SAA24687; Mon, 11 Nov 2002 18:12:37 +0900 (JST) (envelope-from matsuura.nobuaki@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id gAB9Cb3F013873; Mon, 11 Nov 2002 18:12:37 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id gAB9CaDT018918; Mon, 11 Nov 2002 18:12:36 +0900 (JST) Received: from img.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id SAA27806; Mon, 11 Nov 2002 18:12:36 +0900 (JST) Received: from MATSUURA.lab.ntt.co.jp by img.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id SAA18950; Mon, 11 Nov 2002 18:12:34 +0900 (JST) Message-Id: <5.0.2.7.2.20021111174547.03e36398@img.m.ecl.ntt.co.jp> X-Sender: nm011@img.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2 Date: Mon, 11 Nov 2002 18:13:12 +0900 To: Nguyen Thi Mai Trang From: MATSUURA Nobuaki Subject: Re: [NSIS] sender-/receiver-initiated Cc: nsis@ietf.org In-Reply-To: <3DCBD73A.E849C8E9@enst.fr> References: <6D8664171C38D511B5AD0002B325CE66A9351E@mail.cetaceannetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hello Mai Trang, According to the definition in the draft, RSVP seems to be both sender- and receiver-initiated signaling protocol, as you said. I think that there should be a receiver-initiated signaling protocol, in which a receiver initiates the "signaling". (FYI... may be relevant) http://www.ietf.org/internet-drafts/draft-matsuura-reverse-lsp-01.txt Regards, Nobuaki At 02/11/09 00:24, Nguyen Thi Mai Trang wrote: >Hello, > >In the draft-ietf-nsis-req-05.txt, the definition of sender-/receiver initiated >signaling protocol (page 4) is not clear for me. In fact, the word "inititated" >means "initiate the signaling process" or "initiate the reservation"? Are the >"sender" and "receiver" considered over the data stream? > >I take RSVP for example: > >For a data stream from A to B (source = A, destination = B), A initiates the >signaling process by sending PATH message. B initiates the reservation process >by sending RESV message. > >In comparison with sender-initiated definition in the draft, B initiates the >reservation, then RSVP is receiver-initiated signaling protocol. In comparison >with sender-initiated definition in the draft, A initiates the signaling, then >RSVP is sender-initiated signaling protocol. Therefore, RSVP is both sender- and >receiver-initiated protocol !??? > >Another question, what does "the triggering instance" means in the sentence >"However, the triggering instance is not specified" ? > >Thanks for any clarification, >Mai Trang > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 12 05:51: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 FAA26975 for ; Tue, 12 Nov 2002 05:51:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACArjD23644 for nsis-archive@odin.ietf.org; Tue, 12 Nov 2002 05:53: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 gACArhv23633; Tue, 12 Nov 2002 05:53: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 gACAq5v23581 for ; Tue, 12 Nov 2002 05:52:05 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26946 for ; Tue, 12 Nov 2002 05:49:29 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gACAqfB26338 for ; Tue, 12 Nov 2002 12:52:41 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 12 Nov 2002 12:51:55 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 12 Nov 2002 12:51:54 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 12 Nov 2002 12:51:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Key management Date: Tue, 12 Nov 2002 12:51:53 +0200 Message-ID: Thread-Topic: [NSIS] Key management Thread-Index: AcKHtS+aKPYdmGSVTlWwTs6EXGhtsAChDuvQ To: X-OriginalArrivalTime: 12 Nov 2002 10:51:54.0311 (UTC) FILETIME=[8375F570:01C28A39] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gACAq5v23582 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, Just as an FYI, I pinged the Security ADs about attending the Wednesday meeting, so hopefully they can help us out on this discussion. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 12 08:54: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 IAA00454 for ; Tue, 12 Nov 2002 08:54:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACDuLG01093 for nsis-archive@odin.ietf.org; Tue, 12 Nov 2002 08:56:21 -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 gACDuJv01086; Tue, 12 Nov 2002 08:56: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 gACDtKv01023 for ; Tue, 12 Nov 2002 08:55:20 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00388 for ; Tue, 12 Nov 2002 08:52:40 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gACDl3E24967; Tue, 12 Nov 2002 14:47:03 +0100 Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier To: "Freytsis, Ilya" Cc: "'Hancock, Robert'" , Bob Braden , nsis@ietf.org, brunner@ccrle.nec.de X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 12 Nov 2002 14:54:43 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/12/2002 14:54:47 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Ilya, Bob, Robert, all, There seem to be three options each with their pro's and con's: - specific to each new NSLP: allows separate choice for each NSLP - generic and a mandatory component of each NSLP: allows consistent choice for all NSLP, useful for many applications - generic in the NTLP If I understand correctly, we are talking about an identifier that is independent of IP addresses (they could be the flow id for QoS and should go in the NTLP anyway) and cannot be guaranteed to be needed in all applications. Given this, I think it would make sense to make it a mandatory component of each NSLP specification (I am assuming that the actual user of this id will be NSLP and therefore it would make more sense to put it there). Maybe we could foresee a flag in the NTLP to indicate that such an object is present? Sven. "Freytsis, Ilya" @ietf.org on 08/11/2002 15:42:46 Sent by: nsis-admin@ietf.org To: "'Hancock, Robert'" , Bob Braden , nsis@ietf.org, brunner@ccrle.nec.de cc: Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier My comments in-line Regards, Ilya -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: Thursday, November 07, 2002 5:37 PM To: Bob Braden; nsis@ietf.org; brunner@ccrle.nec.de Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Hi, A comment on scope/layering of this reservation identifier thing (if it ever exists): > *> So reformulating the requirement into "An NSIS protocol > MUST support a > *> reservation identifer" would solve the first one. > > OK, although I would say "MUST be able to support". > > BTW, a reservation identifier is presumably a multi-hop > thing, so in my > 2-level model it is a creature of ULSP, i.e., it is carried in an > SAPU. That's good, because non-QoS signaling applications probably > don't have any reservations to identify. I think we need to work through this. 1. As Marcus has said, we are signalling to set up something, and that something is what we want to identify to be able to manipulate - it doesn't matter if it's QoS (and called a reservation) or something else. [IF] That is right to the point. I just want to add that that something is separate from the flow but used by the flow. The main value of the reservation ID in my mind is to enable referencing that something independently from any other characteristics of the flow. The v6 flow label draft calls this something 'flow state' so this identifier could be a "flow state id". Would that be a better term? [IF] I don't think. See the argument above. 2. My feeling is that this XXX-id would be useful for general signalling applications (i.e. if you use the signalling application in a mobile enviroment, efficiently moving the state is something you want to do anyway). Also, providing the facility might be tricky, and might require subtle interworking with other protocols (e.g. mobility ones). In that case, it be better to provide it as a generic service rather than solving the problem for each signalling application. [IF] Agreed. 3. So, wouldn't one want it within the NTLP (lower layer)? [IF] Absolutely. 4. Or, should we be thinking of some kind of 'core' NSLP toolkit which has these generic facilities? [IF] I think it is good way to move forward. Cheers, Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 12 08:55: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 IAA00485 for ; Tue, 12 Nov 2002 08:55:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACDv5Q01198 for nsis-archive@odin.ietf.org; Tue, 12 Nov 2002 08:57:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACDv1v01147; Tue, 12 Nov 2002 08:57: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 gACDuQv01105 for ; Tue, 12 Nov 2002 08:56:26 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00443 for ; Tue, 12 Nov 2002 08:53:50 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id gACDuMN14506 for ; Tue, 12 Nov 2002 14:56:22 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gACDuMB17747 for ; Tue, 12 Nov 2002 14:56:22 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: Date: Tue, 12 Nov 2002 14:57:08 +0100 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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [NSIS] Issue 3: Three security related signaling protocol issues Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi all i tried to compile some security issues which arise when looking at signaling protocols (with RSVP as an example). it would be nice to receive your comments, corrections and thoughts. Three security related signaling protocol issues ------------------------------------------------ 1. First-Peer Issues In case of end-to-end signaling an end host starts signaling to its attached network. The first-peer communication is often more difficult because of the different requirements and a missing trust relationship. An end host must therefore obtain some information to start RSVP signaling: - Does this network support RSVP signaling? - Which node supports RSVP signaling? - To which node is authentication required? - Which identity is used for authentication? - Which security mechanisms are used for authentication? - Which algorithms have to be used? - Where should the keys/security association come from? - Should a security association be established? RSVP, as specified today, is used as a building block. Hence these questions have to be answered as part of overall architectural considerations. Without giving an answer to this question "ad-hoc" RSVP communication by an end host roaming to an unknown network is not possible. A negotiation of security mechanisms and algorithms is not supported for RSVP. 2. Next-Peer Issues It is often assumed that the next RSVP node along the path is always known. Knowing your next peer is important to be able to select the key for the RSVP Integrity object to provide proper protection. In case that an RSVP node assumes to know which node is the next peer then the following protocol exchange can occur: Integrity (A<->C) +------+ (3) | RSVP | +------------->+ Node | | | B | Integrity | +--+---+ (A<->C) | | +------+ (2) +--+---+ | (1) | RSVP +----------->+ | | Error ----->| Node | |Router+<------------+ (I am B) | A +<-----------+ | (4) +------+ (5) +--+---+ Error . (I am B) . +------+ . | RSVP | ...............+ Node | | C | +------+ Figure 1: Next-Peer Problem When RSVP node A in Figure 1 receives an incoming RSVP Path message then standard RSVP message processing takes place. Node A then has to decide which key to select to protect the signaling message. We assume that some mechanism which is not further specified is used to make this decision. In this example node A assumes that the message will travel to RSVP node C. However because of some reasons (e.g. a route change, inability to learn the next RSVP peer along the path, etc.) the message travels to node B via a non-RSVP supporting router which cannot verify the integrity of the message (or cannot decrypt the Kerberos service ticket). The processing failure causes a PathErr message to be returned to the originating sender of the Path message. This error message also contains information about the node recognizing the error. In many cases a security association might not be available. Node A receiving the PathErr message might use the information returned with the PathErr message to select a different security association (or to establish one). The RSVP Path message therefore provides a number of functions: path discovery, detecting route changes, learning of QoS capabilities along the path using the Adspec object, (with some interpretation) next-peer discovery and possibly security association establishment (for example in case of Kerberos). From a security point of view there is a conflict between - Idempotent messages delivery and efficiency Especially the RSVP Path message performs a number of functions. Supporting idempotent message delivery somehow contradicts with security association establishment and efficient message delivery and size. For example a "real" idempotent signaling message would contain enough information to perform security processing without depending on a previously executed message exchange. Adding a Kerberos ticket with every signaling message is, however, very inefficient. Using public key based mechanisms is even more inefficient when included in every message. With public key based protection for idempotent messages there is additionally a risk of introducing denial of service attacks. - RSVP Path message functionality and next-peer discovery To protect an RSVP signaling message (and a RSVP Path message in particular) it is necessary to know the identity of the next RSVP aware node (and some other parameters). Without a mechanism for next-peer discovery an RSVP Path message is also responsible for this task. Without knowing the identity of the next peer the Kerberos principal name is also unknown. The so-called Kerberos user-to-user authentication mechanism is not supported which would allow the receiver to trigger the process of establishing Kerberos authentication is not supported. This issue will again be discussed in relationship with the last-peer problem. It is fair to assume that a RSVP supporting node might not have a security association with all possible RSVP nodes in the neighborhood. Especially for inter-domain signaling or IntServ over DiffServ the number of next-peer RSVP nodes might be considerably large. Hence a node transmitting a RSVP Path message might experience difficulties to properly protect the message if it serves as a means to detect route changes at the same time. It is fair noting that in a intra-domain case this might be possible due to manual configuration in case of a dense distribution of RSVP nodes. Denial of Service Problem An adversary could continuously flooding a node with bogus PathErr messages. A legitimate RSVP node would believe that a change in the path took place. Hence this node would try to select a different security association or try to create one with the indicated node. Hence an adversary can send a PathErr message at any time to confuse an RSVP node. If an adversary is located along somewhere along the path then it might also be possible to act as a man-in-the-middle adversary if either authentication and/or authorization is not performed with the necessary accuracy. 3. Last-Peer Issues This section tries to address practical difficulties when authentication and key establishment is accomplished with a protocol which shows some asymmetry in message processing when executed between two nodes. Kerberos is such a protocol and also the only supported protocol which provides dynamic session key establishment for RSVP. For first-peer communication authentication is typically done between a user and some network in the network (for example the access router). Especially in a mobile environment it is not feasable to authenticate end hosts based on their IP or MAC address. To show the problem the typical processing steps for Kerberos are shown for first-peer communication: a) The end host A learns the identity (i.e. Kerberos principal name) of some entity B. This entity B is either the next RSVP node or a PDPor the next policy aware RSVP node. b) Entity A then requests a ticket granting ticket for the network domain. This assumes that the identity of the network domain is known. c) Entity A then requests a service ticket for entity B which was learned in step (a). d) Entity A includes the service ticket to the RSVP signaling message (inside the policy object). The Kerberos session key is used to protect the entire RSVP signaling message. For last-peer communication this processing step theoretically has to be reversed; entity A is then a node in the network (for example the access router) and entity B is the other end host. This assumes that RSVP signaling is accomplished between two end hosts and not between an end host and a application server. The access router might however in step (a) not be able to learn the identity of the user's principal name since this information might not be available. Entity A could reverse the process by triggering an IAKERB exchange. This would cause entity B to request a service ticket for A as described above. IAKERB is, however, not supported. --------------------------------- ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 12 08:55: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 IAA00493 for ; Tue, 12 Nov 2002 08:55:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACDv6J01213 for nsis-archive@odin.ietf.org; Tue, 12 Nov 2002 08: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 gACDv2v01167; Tue, 12 Nov 2002 08:57: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 gACDuXv01113 for ; Tue, 12 Nov 2002 08:56:33 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00450 for ; Tue, 12 Nov 2002 08:53:57 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gACDuTY27428 for ; Tue, 12 Nov 2002 14:56:29 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gACDuTB17882 for ; Tue, 12 Nov 2002 14:56:29 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: Date: Tue, 12 Nov 2002 14:57:15 +0100 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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [NSIS] Issue 1: IPsec protection of RSVP Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi all based on our recent discussion about ipsec protection of rsvp signaling message i tried to write a more detailed text explaining the different issues. i would be nice to receive some feedback: IPsec protection of RSVP signaling messages ------------------------------------------- It was often mentioned that RSVP signaling messages can be protected by IPsec in a hop-by-hop fashion between two adjacent RSVP nodes. Some RSVP signaling message require, however, special processing which complicates IPsec protection. This section tries to describe these complications. RSVP messages are transmitted as raw IP datagrams with protocol number 46. It might be possible to encapsulate them in UDP as described in Appendix C of RFC 2205. Some RSVP messages (Path, PathTear, and ResvConf) must have the Router Alert IP Option set in the IP header. These messages are addressed to the (unicast or multicast) destination address and not to the next RSVP node along the path. Hence an IPsec traffic selector can only use these fields for IPsec SA selection. If there is only a single path (and possibly every traffic is protected) then there is no problem for IPsec protection of signaling messages. This type of protection is not common and might only be used to secure network access between an end host and its first-hop router. Since the described RSVP messages are addressed to the destination address instead of the next RSVP node it is not possible to use IPsec in transport mode - only IPsec in tunnel mode is possible. If there is more than one possible path which an RSVP message can take then the IPsec engine will experience difficulties to protect the message. Even if the RSVP daemon installs a traffic selector with the destination ip address then still there is no distinguishing element which allows to select the correct security association of one of the possible RSVP nodes along. Even if it possible to apply IPsec protection (in tunnel mode) for RSVP signaling messages by incorporating some additional information then there is still the possibility that the tunneled messages do not recognize a path change in a non-RSVP router. Then the signaling messages would simply follow different path than the data. RSVP messages like Resv can be protected by IPsec since they are contain enough information to create IPsec traffic selectors which allow a differentiation between different next RSVP nodes. A traffic selector would then contain the protocol number and the source / destination address pair. ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 12 08:55: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 IAA00511 for ; Tue, 12 Nov 2002 08:55:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACDv8v01225 for nsis-archive@odin.ietf.org; Tue, 12 Nov 2002 08:57: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 gACDv3v01182; Tue, 12 Nov 2002 08:57: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 gACDuXv01117 for ; Tue, 12 Nov 2002 08:56:33 -0500 Received: from thoth.sbs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00451 for ; Tue, 12 Nov 2002 08:53:57 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id gACDuTh02961 for ; Tue, 12 Nov 2002 14:56:29 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gACDuTB17891 for ; Tue, 12 Nov 2002 14:56:29 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: Date: Tue, 12 Nov 2002 14:57:16 +0100 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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [NSIS] Issue 2: Implications of IPsec protected data traffic Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi all at the last ietf meeting i was asked about the implications of ipsec protected data traffic for rsvp. please send me your comments. Implications of IPsec protected data traffic -------------------------------------------- QoS signaling requires flow information to be established at routers along a path. This flow identifier installed at each devices tells the router which data packets should experience QoS treatment. RSVP typically establishes a flow identifier based on the 5-tuple (source IP address, destination IP address, tranport protocol type, source port and destination port). If this 5-tuple information is not available then other identifiers have to be used. IPsec protected data traffic is such an example where the transport protocol and the port numbers are not accessible. Hence the IPsec SPI is used as a substitute for them. RFC 2207 considers these IPsec implications for RSVP and is based on three assumptions: a) An end host, which initiates the RSVP signaling message exchange, has to be able to retrieve the SPI for given flow. This requires some interaction with the IPsec SADB and SPD. An application usually does not know the SPI of the protected flow and cannot provide the desired values. It can provide the signaling protocol daemon with flow identifiers. The signaling daemon would then need to query the IPsec security association database by providing the flow identifiers as input parameters and the SPI as an output parameter. b) RFC 2207 assumes an end-to-end IPsec protection of the data traffic. In IPsec is applied in a nested fashion then parts of the path do not experience QoS treatment. This problem can be treated as a tunneling problem but is initiated by the end host. A figure better illustrates the problem in case of enforcing secure network access: +------+ +---------------+ +--------+ +------+ | Host | | Security | | Router | | Host | | A | | Gateway (SGW) | | Rx | | B | +--+---+ +-------+-------+ +----+---+ +--+---+ | | | | |IPSec-Data( | | | | OuterSrc=A, | | | | OuterDst=SGW, | | | | SPI=SPI1, | | | | InnerSrc=A, | | | | OuterDst=B, | | | | Protocol=X, |IPSec-Data( | | | SrcPort=Y, | SrcIP=A, | | | DstPort=Z) | DstIP=B, | | |=====================>| Protocol=X, |IPSec-Data( | | | SrcPort=Y, | SrcIP=A, | | --IPsec protected-> | DstPort=Z) | DstIP=B, | | data traffic |------------------>| Protocol=X, | | | | SrcPort=Y, | | | | DstPort=Z) | | | |---------------->| | | | | | | --Unprotected data traffic-> | | | | | Figure 1: Next-Peer Problem Host A transmitting data traffic would either indicate a 3-tuple or a 5-tuple . In any case it is not possible to make a QoS reservation for the entire path. Similar examples are remote access using a VPN, protection of data traffic between the home agent (or a security gateway in the home network) and the mobile node and other. With a nested application of IPsec (for example IPsec between A and SGW and between A and B) the same problem occurs. One possible solution to this problem is to change the flow identifier along the path to capture the new flow identifier after an IPsec endpoint. IPsec tunnels which neither start nor terminate at one of the signaling end points (for example between two networks) should be addressed differently by recursively applying an RSVP signaling exchange for the IPsec tunnel. RSVP signaling within tunnels is addressed in RFC 2746. c) It is assumed that SPIs do not change during the lifetime of the established QoS reservation. If a new IPsec SA is created then a new SPI is allocated for the security association. To reflect this change either a new reservation has to be established or the flow identifier of the existing reservation has to be updated. Since IPsec SAs have a longer lifetime this issue does not seem to be a major issue. IPsec protection of SCTP data traffic might more often require an IPsec SA (and an SPI) change to reflect added and removed IP addresses from an SCTP association. ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 12 09:58:34 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 JAA01816 for ; Tue, 12 Nov 2002 09:58:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACF0d804968 for nsis-archive@odin.ietf.org; Tue, 12 Nov 2002 10:00:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACF0av04961; Tue, 12 Nov 2002 10:00:36 -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 gACExpv04794 for ; Tue, 12 Nov 2002 09:59:51 -0500 Received: from [172.1.1.10] (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01733 for ; Tue, 12 Nov 2002 09:57:13 -0500 (EST) Received: from mail.carrieraccess.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 12 Nov 2002 07:59:44 -0700 Received: by newman.carrieraccess.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Nov 2002 07:59:40 -0700 Message-ID: From: "Avella, Alejandro" To: nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-fu-rsvp-multicast-analysis-01.txt Date: Tue, 12 Nov 2002 07:59:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative ; boundary="----_=_NextPart_001_01C28A5C.1FF4DAC0" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling 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_01C28A5C.1FF4DAC0 Content-Type: text/plain; charset="iso-8859-1" To the authors of draft-fu-rsvp-multicast-analysis-01.txt, 1.- Could you point me to data supporting the sentence that multicast applications have been used less frequently than unicast? 2.- Even if multicast is used less today, is there data supporting this trend in the future? Thanks, Alejandro -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, October 28, 2002 4:28 AM Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-fu-rsvp-multicast-analysis-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis on RSVP Regarding Multicast Author(s) : X. Fu, C. Kappler, H. Tschofenig Filename : draft-fu-rsvp-multicast-analysis-01.txt Pages : 14 Date : 2002-10-25 RSVP version 1 has been designed for optimum support multicast. However, in reality multicast is being used much less frequently than anticipated. Still, even for unicast (one sender, one receiver) full-fledged multicast-enabled RSVP signaling must be used. As pointed out in the NSIS requirement draft, multicast would not be necessarily required for an NSIS signaling protocol. This draft analyses ingredients of RSVP Version 1 which are affected by multicast, and derives how these ingredients may look like if multicast is not supported in the generic RSVP signaling protocol and adapt related functionalities accordingly - we call the resulting feature set 'RSVP Lite', a potentially more light-weight version of RSVP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fu-rsvp-multicast-analysis-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-fu-rsvp-multicast-analysis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-fu-rsvp-multicast-analysis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ************************************************************************* This e-mail transmission, and any documents, files, or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution, or use of any of the information contained in or attached to this transmission is strictly prohibited. If you have received this transmission in error, please immediately notify the sender by telephone or return e-mail and delete the original transmission and its attachments without reading or saving them in any manner. Thank you. ************************************************************************* ------_=_NextPart_001_01C28A5C.1FF4DAC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] I-D ACTION:draft-fu-rsvp-multicast-analysis-01.txt

To the authors of draft-fu-rsvp-multicast-analysis-01.txt= ,

1.- Could you point me to data supporting the sentence th= at multicast applications have been used less frequently than unicast?

2.- Even if multicast is used less today, is there data s= upporting this trend in the future?

Thanks,

Alejandro

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Monday, October 28, 2002 4:28 AM
Cc: nsis@ietf.org
Subject: [NSIS] I-D ACTION:draft-fu-rsvp-multicast-analy= sis-01.txt


A New Internet-Draft is available from the on-line Intern= et-Drafts directories.


        Title &nb= sp;         : Analysis on RSVP Regarding= Multicast
        Author(s)&nbs= p;      : X. Fu, C. Kappler, H. Tschofenig
        Filename = ;       : draft-fu-rsvp-multicast-analysis-01= .txt
        Pages &n= bsp;         : 14
        Date &nb= sp;          : 2002-10-25
       =20
RSVP version 1 has been designed for optimum support mul= ticast.
However, in reality multicast is being used much less fr= equently than
anticipated.  Still, even for unicast (one sender, = one receiver)
full-fledged multicast-enabled RSVP signaling must be us= ed.  As
pointed out in the NSIS requirement draft, multicast wou= ld not be
necessarily required for an NSIS signaling protocol.&nbs= p; This draft
analyses ingredients of RSVP Version 1 which are affecte= d by
multicast, and derives how these ingredients may look li= ke if
multicast is not supported in the generic RSVP signaling= protocol and
adapt related functionalities accordingly - we call the = resulting
feature set 'RSVP Lite', a potentially more light-weight= version of
RSVP.

A URL for this Internet-Draft is:
http://www.ietf.org/inter= net-drafts/draft-fu-rsvp-multicast-analysis-01.txt

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

Internet-Drafts are also available by anonymous FTP. Logi= n with the username
"anonymous" and a password of your e-mail addr= ess. After logging in,
type "cd internet-drafts" and then
        "get dra= ft-fu-rsvp-multicast-analysis-01.txt".

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


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

Send a message to:
        mailserv@ietf= .org.
In the body type:
        "FILE /i= nternet-drafts/draft-fu-rsvp-multicast-analysis-01.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, inse= rt the command "ENCODING mime" before the "FILE"
        command. = ; To decode the response(s), you will need "munpack" or
        a MIME-compli= ant mail reader.  Different MIME-compliant mail readers
        exhibit diffe= rent behavior, especially when dealing with
        "multipa= rt" MIME messages (i.e. documents which have been split
        up into multi= ple messages), so check your local documentation on
        how to manipu= late these messages.
            &nbs= p;  =20
            &nbs= p;  =20
Below is the data which will enable a MIME compliant mai= l reader
implementation to automatically retrieve the ASCII versi= on of the
Internet-Draft.



************************************************************************* This e-mail transmission, and any documents, files, or previous
e-mail messages attached to it may contain information that is
confidential or legally privileged. If you are not the intended
recipient, or a person responsible for delivering it to the
intended recipient, you are hereby notified that you must not
read this transmission and that any disclosure, copying, printing,
distribution, or use of any of the information contained in or
attached to this transmission is strictly prohibited. If you have
received this transmission in error, please immediately notify the
sender by telephone or return e-mail and delete the original
transmission and its attachments without reading or saving them
in any manner. Thank you.
************************************************************************* ------_=_NextPart_001_01C28A5C.1FF4DAC0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 12 10:04: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 KAA02088 for ; Tue, 12 Nov 2002 10:04:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACF69t05364 for nsis-archive@odin.ietf.org; Tue, 12 Nov 2002 10:06:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACF64v05341; Tue, 12 Nov 2002 10:06: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 gACF57v05305 for ; Tue, 12 Nov 2002 10:05:07 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02019 for ; Tue, 12 Nov 2002 10:02:30 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 12 Nov 2002 16:05:02 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Nov 2002 16:05:02 +0100 Message-Id: From: "Geib, Ruediger" To: sven.van_den_bosch@alcatel.be Cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Date: Tue, 12 Nov 2002 16:04:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gACF57v05306 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Sven, > If I understand correctly, we are talking about an identifier that is > independent of IP addresses As I've mentioned earlier, the reservation ID must be non-ambiguous within the Internet. Having a reservation ID based on a single IP address (e.g. sender IP address) and a reservation number would be a reasonable choice. Should the design of the reservation ID be independant of IP addresses, a new regulated ID space may result to ensure non ambiguity within the Internet. I'd prefer protocols without reservation ID in this case. Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 12 10:42: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 KAA03505 for ; Tue, 12 Nov 2002 10:42:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACFiHJ08795 for nsis-archive@odin.ietf.org; Tue, 12 Nov 2002 10:44: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 gACFiFv08786; Tue, 12 Nov 2002 10:44: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 gACFhEv08709 for ; Tue, 12 Nov 2002 10:43:14 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03346 for ; Tue, 12 Nov 2002 10:40:35 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gACFZKd30772; Tue, 12 Nov 2002 16:35:20 +0100 Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier To: "Geib, Ruediger" Cc: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 12 Nov 2002 16:43:00 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/12/2002 16:43:03 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gACFhEv08710 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Ruediger, I have seen your point. First, I think we can assume that the source/destination IP address will be present in NTLP or NSLP and that we can combine that one plus the reservation number to the reservation ID. Assuming that source/destination address are present in NTLP anyhow, this would reduce the problem to a non-IP address dependent reservation number. The other issue I have (I may have missed other people's comments) is that with your proposal you cannot guarantee uniqueness in the presence of NAT. Then, in principle, it would be possible to have the same ID twice (same IP address(es) and same reservation number). The possibility would be reduced if an end-point assembles an ID based on a local IP address and a reservation ID and NTLP contains IP adresses (those would be translated with NAT, the original one would remain) but even then I guess you cannot completely guarantee uniqueness. What do you think? Sven. "Geib, Ruediger" on 12/11/2002 16:04:59 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: nsis@ietf.org Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Hi Sven, > If I understand correctly, we are talking about an identifier that is > independent of IP addresses As I've mentioned earlier, the reservation ID must be non-ambiguous within the Internet. Having a reservation ID based on a single IP address (e.g. sender IP address) and a reservation number would be a reasonable choice. Should the design of the reservation ID be independant of IP addresses, a new regulated ID space may result to ensure non ambiguity within the Internet. I'd prefer protocols without reservation ID in this case. Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 12 10:55: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 KAA04252 for ; Tue, 12 Nov 2002 10:55:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACFv8s09648 for nsis-archive@odin.ietf.org; Tue, 12 Nov 2002 10:57: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 gACFv5v09640; Tue, 12 Nov 2002 10:57: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 gACFusv09623 for ; Tue, 12 Nov 2002 10:56:54 -0500 Received: from s2 (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04231 for ; Tue, 12 Nov 2002 10:54:17 -0500 (EST) Received: from cs.uni-goettingen.de (ap12.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.44]) (AUTH: LOGIN fu) by s2 with esmtp; Tue, 12 Nov 2002 16:56:49 +0100 Message-ID: <3DD1247E.FFC3B680@cs.uni-goettingen.de> Date: Tue, 12 Nov 2002 16:55:42 +0100 From: Xiaoming Fu X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Avella, Alejandro" CC: nsis@ietf.org Subject: Re: [NSIS] I-D ACTION:draft-fu-rsvp-multicast-analysis-01.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alejandro, Thanks for your questions regarding the I-D. 1- e.g., you may find some multicast deployment data in http://www.multicasttech.com/multicast_faq.html "At present (mid-April, 2001), the penetration of multicast into the commodity Internet seems to be between 3 and 5 per cent." 2- there are a lot of research efforts on multicast since the 1980s, and there are a number of benefits that multicast could deliver for the providers and customers, however, like IP QoS, it might be the case we have to expect a universal deployment of multicast in the Internet as a relatively long-time process, IMHO. Cheers, Xiaoming "Avella, Alejandro" wrote: > To the authors of draft-fu-rsvp-multicast-analysis-01.txt, > > 1.- Could you point me to data supporting the sentence that multicast > applications have been used less frequently than unicast? > > 2.- Even if multicast is used less today, is there data supporting > this trend in the future? > > Thanks, > > Alejandro > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, October 28, 2002 4:28 AM > Cc: nsis@ietf.org > Subject: [NSIS] I-D ACTION:draft-fu-rsvp-multicast-analysis-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Analysis on RSVP Regarding Multicast > Author(s) : X. Fu, C. Kappler, H. Tschofenig > Filename : draft-fu-rsvp-multicast-analysis-01.txt > Pages : 14 > Date : 2002-10-25 > > RSVP version 1 has been designed for optimum support multicast. > However, in reality multicast is being used much less frequently than > anticipated. Still, even for unicast (one sender, one receiver) > full-fledged multicast-enabled RSVP signaling must be used. As > pointed out in the NSIS requirement draft, multicast would not be > necessarily required for an NSIS signaling protocol. This draft > analyses ingredients of RSVP Version 1 which are affected by > multicast, and derives how these ingredients may look like if > multicast is not supported in the generic RSVP signaling protocol and > adapt related functionalities accordingly - we call the resulting > feature set 'RSVP Lite', a potentially more light-weight version of > RSVP. > > A URL for this Internet-Draft is: > > ttp://www.ietf.org/internet-drafts/draft-fu-rsvp-multicast-analysis-01.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-fu-rsvp-multicast-analysis-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-fu-rsvp-multicast-analysis-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" > or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been > split > up into multiple messages), so check your local documentation > on > how to manipulate these messages. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 12 12:26: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 MAA07493 for ; Tue, 12 Nov 2002 12:26:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACHSPH15916 for nsis-archive@odin.ietf.org; Tue, 12 Nov 2002 12:28: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 gACHSMv15908; Tue, 12 Nov 2002 12:28: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 gACHRSv15877 for ; Tue, 12 Nov 2002 12:27:28 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07471 for ; Tue, 12 Nov 2002 12:24:49 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Nov 2002 17:27:22 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5E07@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Melinda Shore , nsis@ietf.org Date: Tue, 12 Nov 2002 17:27:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] RE: what's part of NSIS? (was: RE: Comments on framework draft) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Melinda, more follow up comments: > 4.2 Writing in para starting "We have a > basic design goal" is a little unclear - why not simply > state that we assume the following functions will be > available by other means and are therefore will not be > included in the NSIS protocol? broadly I probably agree, with some modifications reflecting what has actually happened since the -00 version. The -00 version referred to three out of scope things: 1) since i suspect we are now more open to looking at particular signalling applications, I'm no longer happier about asserting that "Negotiation of service configuration" is out of scope, but instead it's obviously a question specific to the signalling application in question (so this particular factoid probably doesn't need to be mentioned here). 2) "Agreement to use NSIS for signaling" (and initiator selection) being something that happens outside NSIS seems a reasonable assumption, that could now go in 3.3.1. 3) The bit about peer discovery/selection has been clarified anyway, but in any case has nothing to do with upper layer services (I think?). So it should probably move elsewhere (maybe into its own section about how the end to end path actually gets tracked). Are there other necessary stages in the overall signalling process which we think we should identify as not being NSIS's job to solve? It would be good if we could think of some... > 6.1 seems to assume the use of an external security protocol > aside from key management (IPSec, SSL). Does it need > to? What about authenticating individual elements? I think this one has been discussed extensively already. I don't think we have finalised a 'make or buy' decision on security mechanism yet (this could be clarified I guess). If by "What about authenticating individual elements?" you mean securing individual information elements in messages (a la CMS for example), this should be mentioned. (The original discussion was very much with only the NTLP in mind, for which the technique seems less natural - in other words, this becomes another "what's appropriate for what layer" question.) > 6.2 I'd restate question as "Does the requestor have > permission?" Payment, etc. may very well not enter into > it. No negotiation! Request has a yes/no/"no but" > answer with possibility of additional information > ("these are the nodes that would not satisfy the request > and this is the reason they gave"), but negotiation > introduces complexity with no real advantages. We can rephrase the first sentence of 6.2 in terms of "permission" rather than "payment", but I'd like to keep the latter term as well just to wake people up (as Mike has done on the same subject). OTOH, I don't see that we can absolutely rule out negotiation as part of the process, and in fact, if the NTLP is properly transparent, I don't see any way to write the framework to prevent someone putting it in to the NSLP for their favourite signalling application. Do you? Nearly done, Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 12 12:55:00 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 MAA08193 for ; Tue, 12 Nov 2002 12:55:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gACHv7V17599 for nsis-archive@odin.ietf.org; Tue, 12 Nov 2002 12:57: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 gACHv5v17592; Tue, 12 Nov 2002 12:57: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 gACHuuv17562 for ; Tue, 12 Nov 2002 12:56: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 MAA08147 for ; Tue, 12 Nov 2002 12:54:17 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gACHufaE015770; Tue, 12 Nov 2002 09:56:41 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAO46096; Tue, 12 Nov 2002 09:51:06 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA15240; Tue, 12 Nov 2002 09:56:48 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15825.16608.594807.343770@thomasm-u1.cisco.com> Date: Tue, 12 Nov 2002 09:56:48 -0800 (PST) To: Cc: "Michael Thomas" , "Bob Braden" , Subject: RE: [NSIS] Key management In-Reply-To: References: <15820.41993.361955.805653@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hannes Tschofenig writes: > hi mike! > > i guess the problem pointed out here is that > - if you want to secure rsvp traffic in a hop-by-hop fashion then you need > to have some traffic selector which knows which ipsec sa to apply. if you > however have more than one possible path then you might experience problems > when selecting the security association since the ip packet is addressed to > the destination and not to the next host (at least for the rsvp path > message). Hannes, A point I brought up in the MIP WG is that there are two general ways one can envision using IPsec: 1) Use IPsec as a filtering mechanism such that unauthorized traffic is not able to make it into the unprotected part of the network/kernel/apps. I believe that is the model you are suggesting here. 2) You use IPsec as a means of blocking unauthenticated traffic (ie, all packets you receive will be bound to strong credentials) and you push the authorization check up to the app. The advantage of the second is that you can divorce yourself from IP address based filtering and all of the unpleasant side effects that brings (eg, the slippery slope of IPaddr == identity). Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 03:28: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 DAA24584 for ; Wed, 13 Nov 2002 03:28:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAD8UWh11842 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 03: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 gAD8USv11835; Wed, 13 Nov 2002 03:30: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 gAD8Tmv11801 for ; Wed, 13 Nov 2002 03:29:48 -0500 Received: from thoth.sbs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24577 for ; Wed, 13 Nov 2002 03:27:03 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id gAD8Tah13763; Wed, 13 Nov 2002 09:29:36 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gAD8TaB08992; Wed, 13 Nov 2002 09:29:36 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Michael Thomas" , "Melinda Shore" Cc: "Bob Braden" , Date: Wed, 13 Nov 2002 09:30:19 +0100 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) In-Reply-To: <15820.208.279869.225858@thomasm-u1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [NSIS] accouting issues & rsvp Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi mike! > #include > > This is not a small point. One of things my draft > went into at some length is the fact that I couldn't > figure out what sort of accounting model for lack of > a better phrase was intended for policy objects. When > the receiver sends RESV's and there are potentially > many PEP's in the path, who's responsible for supplying > those policy objects? I couldn't find any guidance in > RFC 2750. Are they loaded up front by the receiver, > or can they be inserted hopwise (sort of a relay model)? > The one thing I'm pretty certain of is that cross realm > RSVP with policy will probably not work. > initially i was also confused about the usage of policy objects in rsvp and their relationship to accouting. then i found the following document written by shai herzog: Building Blocks for Accounting and Access Control in RSVP. the document was also published as an ietf draft a long time ago (draft-ietf-rsvp-lpm-arch-00.txt). it gives a good overview how these objects are used. you might want to take a look at it. i have to agree with bob that the receiver-initiated signaling approach of rsvp does not necessarily mean that the receiver has to pay. ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 04:08: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 EAA25415 for ; Wed, 13 Nov 2002 04:08:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAD9AM314843 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 04:10: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 gAD9AJv14806; Wed, 13 Nov 2002 04:10: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 gAD99vv14750 for ; Wed, 13 Nov 2002 04:09:57 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25385 for ; Wed, 13 Nov 2002 04:07:11 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id gAD99iN14675; Wed, 13 Nov 2002 10:09:44 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gAD99iB20445; Wed, 13 Nov 2002 10:09:44 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Melinda Shore" , Date: Wed, 13 Nov 2002 10:10:26 +0100 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) In-Reply-To: <15825.16608.594807.343770@thomasm-u1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [NSIS] security - transport/application layer Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi melinda in one of your previous mails you raised the question of where to apply security protection: i try to give an example based on rsvp: (my) assumptions: - ip is the transport - everything else is the application example: - the rsvp integrity object does not provide protection of the transport . - if you use ipsec (if you can) then you would also protect the transport mechanism of rsvp. - rsvp also allows a second integrity object to be used: the integrity object within the policy object. depending on the configuration of your nodes a rsvp aware node might also be a policy aware node. if so then you protect your rsvp message with the integrity object and additionally the policy object with another integrity object. a kerberos ticket in the policy object might allow key management to support keys maybe (my interpretation) for both objects. assuming the a different configuration you would allow end-to-middle security: host a <-------> rsvp aware node (not policy aware) <-------> rsvp and policy aware node |-----peer-to-peer--------------| |-----peer-to-peer--------------| |---------------------------------end-to-middle---------------------------| if security protection terminates at different places then you need to think about the key managment for both. > But again, I think this is a problem for the application, > not the transport. The transport needs to protect itself > against forgeries, theft of service, etc., and I don't think > it's necessarily the job of the NSIS transport to protect > the NSIS application. ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 04: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 EAA25429 for ; Wed, 13 Nov 2002 04:08:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAD9AOJ14855 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 04:10:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAD9AKv14821; Wed, 13 Nov 2002 04:10: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 gAD99wv14754 for ; Wed, 13 Nov 2002 04:09:58 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25388 for ; Wed, 13 Nov 2002 04:07:12 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gAD99iY00912; Wed, 13 Nov 2002 10:09:44 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gAD99iB20458; Wed, 13 Nov 2002 10:09:44 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Bob Braden" , Cc: , Date: Wed, 13 Nov 2002 10:10:27 +0100 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) In-Reply-To: <200211081748.RAA06453@gra.isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [NSIS] chain of trust Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi bob it was often mentioned that the chain of trust (=transitive trust) model breaks if one of the nodes along the path is compromised. this is true, but it is hard to find an approach which is much better considering the way how a signaling protocol work. some published qos security paper addressed this issue and applied additional security protection on top of the hop-by-hop security protection. unfortunately this might not solve all problem and additionally introduces performance problems. the functionality of a signaling protocol might make it difficult to decide whether something is an attack or a failure behavior. a short comment to end-to-end security: i do not believe that end-to-end security for qos signaling is really an option for the following reasons: - a signaling protocol requires intermediate nodes to inspect, modify and add message parts. hence only some non-mutuable fields can be protected or incremental protection. the meaning for an end host might be questionable. - protocol operations like proxying might require some sort of delegation. - applying end-to-end security between two arbitrary hosts might be a deployment problem in general if there are some objects which are only relevant for end hosts (and not for intermediate nodes at all) then why is it necessary to ship them with a signaling protocol. ciao hannes > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Bob > Braden > Sent: Friday, November 08, 2002 6:49 PM > To: braden@ISI.EDU; mshore@cisco.com > Cc: mat@cisco.com; nsis@ietf.org > Subject: Re: [NSIS] Key management > > > > *> From mshore@cisco.com Fri Nov 8 09:24:37 2002 > *> To: Bob Braden > *> cc: mat@cisco.com, nsis@ietf.org > *> From: Melinda Shore > *> Subject: Re: [NSIS] Key management > *> Date: Fri, 08 Nov 2002 12:24:21 -0500 > *> X-AntiVirus: scanned by AMaViS 0.2.1 > *> > *> > 1) IPSEC bases security associations on the IP dst > address. RSVP had > *> > security associations with the next RSVP capable > router along the path. > *> > *> That still leaves the possibility of establishing IPSec SAs > *> between individual routers rather than end-to-end. We've > *> been talking about doing hop-by-hop security anyway. > *> > > Melinda, > > (Believe me, the RSVP WG really did NOT want to invent any new > security mechanism, and we tried hard to use IPsec. but...) > > No, that doesn't help. A Path message still has the session address as > its IP destination address, not the next hop address, and that is what > IPsec looks at. > > *> Still, among the things that we need to consider is that for > *> the NSIS application (or whatever we're calling it today) > *> that needs security services across hops (end-to-end or > *> end-to-middle) this effectively means that the transport > *> layer isn't really secure since some devices that are along > *> the path but not participating may be decrypting and > *> re-encrypting (or verifying and re-authenticating) messages > *> in the transport layer, and they can peer into packet > *> contents, or change them. > > I don't understand. Devices along the path are either NSIS-trusted > and have keys for NSIS neighbors, or they aren't. Maybe you are > pointing out the inherent insecurity of the transitive trust model, > that worries the security folks? Sorry if I am missing something. > > Bob > > > *> > *> > 2) IPSEC did not adequately support multicast at > the time (i.e. a > *> > security association based on a logical (group) > destination address, > *> > rather than a physical unicast destination address). > *> > *> This is still more-or-less true; the msec working group is > *> hard at work but I don't think they've gotten any documents > *> into WG last call yet. > *> > *> Melinda > *> > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 04: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 EAA25442 for ; Wed, 13 Nov 2002 04:08:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAD9AP014868 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 04:10: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 gAD9ALv14836; Wed, 13 Nov 2002 04:10: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 gAD99wv14757 for ; Wed, 13 Nov 2002 04:09:58 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25390 for ; Wed, 13 Nov 2002 04:07:12 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id gAD99jN14680; Wed, 13 Nov 2002 10:09:45 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gAD99iB20464; Wed, 13 Nov 2002 10:09:44 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Melinda Shore" , "Bob Braden" Cc: , Subject: RE: [NSIS] Key management - Nat involvement Date: Wed, 13 Nov 2002 10:10:27 +0100 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) In-Reply-To: <200211081803.AAS64421@mira-sjc5-4.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi melinda! why do you think that a nat might be able to get the key material of a different nat? sender <--------> Nat1 <------------> Nat2 <-----------> receiver if peer-to-peer security is used then a signaling message is secured between sender and nat1 and again secured between the two nats. if you only use peer-to-peer security then the sender trusts the nodes along the path to work in the expected way. a corrupted nat might for example create a wrong nat binding and you would not be able to detect it. but this results from the way how signaling protocols work. ciao hannes > Transitivity may work for identity authentication but I'm > less comfortable with it for things like confidentiality. > That is to say, identity (are you are who you say you are?) > is a yes/no question, assuming that you have a high degree > of confidence in the authentication mechanism in every hop > along the path. > > I think that when things like access policy are involved the > question becomes stickier. Let's say that I've got two NATs > in the path and they belong to two different administrative > domains (they have independent administrative policies). If > we rely on hop-by-hop security, the first NAT in the path > (with respect to the sender) is going to get a copy of the > second NAT's keying material, assuming that we use some sort > of key exchange rather than either using pre-shared keys or > doing some sort of public-key based key exchange at this > layer, as well, which can be quite costly. Whether or not > you trust that first NAT with the second NAT's keys is going > to be a matter of policy, and while the question of provable > identity isn't orthogonal to that question it's at least at > a slight tilt. > > But again, I think this is a problem for the application, > not the transport. The transport needs to protect itself > against forgeries, theft of service, etc., and I don't think > it's necessarily the job of the NSIS transport to protect > the NSIS application. > > Melinda > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 04:11:50 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 EAA25612 for ; Wed, 13 Nov 2002 04:11:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAD9E4n15086 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 04:14: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 gAD9E2v15069; Wed, 13 Nov 2002 04:14: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 gAD9D8v15018 for ; Wed, 13 Nov 2002 04:13:08 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25564 for ; Wed, 13 Nov 2002 04:10:22 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gAD9CsY02918; Wed, 13 Nov 2002 10:12:55 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gAD9CsB23391; Wed, 13 Nov 2002 10:12:54 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Michael Thomas" Cc: "Bob Braden" , Subject: RE: [NSIS] Key management Date: Wed, 13 Nov 2002 10:13:37 +0100 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) In-Reply-To: <15825.16608.594807.343770@thomasm-u1.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi mike please see my comments inline: > Hannes Tschofenig writes: > > hi mike! > > > > i guess the problem pointed out here is that > > - if you want to secure rsvp traffic in a hop-by-hop fashion > then you need > > to have some traffic selector which knows which ipsec sa to > apply. if you > > however have more than one possible path then you might > experience problems > > when selecting the security association since the ip packet is > addressed to > > the destination and not to the next host (at least for the rsvp path > > message). > > Hannes, > > A point I brought up in the MIP WG is that there > are two general ways one can envision using IPsec: > > 1) Use IPsec as a filtering mechanism such that unauthorized > traffic is not able to make it into the unprotected > part of the network/kernel/apps. I believe that is the > model you are suggesting here. > > 2) You use IPsec as a means of blocking unauthenticated > traffic (ie, all packets you receive will be bound to > strong credentials) and you push the authorization > check up to the app. > > The advantage of the second is that you can > divorce yourself from IP address based filtering > and all of the unpleasant side effects that brings > (eg, the slippery slope of IPaddr == identity). this is a good categorization. both models related to each other. my intention at this point was only to raise signaling protocol protection and not data traffic. there is clearly some relationship to nsis. in case of (1) i think you speak about secure network access. ip spoofing threats can be prevented by using this model. your second model is certainly a resonable approach. you do not really need ip addresses as identities since you execute an authentication and key exchange protocol before you can use ipsec sas. these identities can then also be used for authorization and accounting. i hope i got your point. ciao hannes > > Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 04:15: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 EAA25731 for ; Wed, 13 Nov 2002 04:15:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAD9ICk15257 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 04:18: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 gAD9IAv15229; Wed, 13 Nov 2002 04:18: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 gAD9HJv15180 for ; Wed, 13 Nov 2002 04:17:19 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25665 for ; Wed, 13 Nov 2002 04:14:33 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAD9HiB00362 for ; Wed, 13 Nov 2002 11:17:44 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Nov 2002 11:17:04 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 13 Nov 2002 11:17:04 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 13 Nov 2002 11:17:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Key management - Nat involvement Date: Wed, 13 Nov 2002 11:16:51 +0200 Message-ID: Thread-Topic: [NSIS] Key management - Nat involvement Thread-Index: AcKK9IOD/yJZEFEVSDKT0uWxT6NwWQAAFuQQ To: , , Cc: , X-OriginalArrivalTime: 13 Nov 2002 09:17:00.0514 (UTC) FILETIME=[6C1B3C20:01C28AF5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAD9HJv15181 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Hannes, > why do you think that a nat might be able to get the key material of a > different nat? > > sender <--------> Nat1 <------------> Nat2 <-----------> receiver > > if peer-to-peer security is used then a signaling message is secured > between sender and nat1 and again secured between the two nats. if you only > use peer-to-peer security then the sender trusts the nodes along the path to > work in the expected way. a corrupted nat might for example create a wrong > nat binding and you would not be able to detect it. but this results from > the way how signaling protocols work. So, the Security Area has gone on record that this sort of transitive trust is inherently insecure, as the sender has know knowledge of the entities along the path, therefore is in no possition to assess the security risk. As a corrupted or compromised node could inflict much damage, as the sender assumes that signaling is secured. Therefore, we cannot reply on peer-to-peer security, but have to be able to have an end-to-end mechanism. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 04:25: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 EAA25884 for ; Wed, 13 Nov 2002 04:25:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAD9S7W15720 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 04:28: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 gAD9S5v15712; Wed, 13 Nov 2002 04:28: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 gAD9Rpv15696 for ; Wed, 13 Nov 2002 04:27:51 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25881 for ; Wed, 13 Nov 2002 04:25:05 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAD9SDB09077 for ; Wed, 13 Nov 2002 11:28:13 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Nov 2002 11:27:03 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 13 Nov 2002 11:27:03 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 13 Nov 2002 11:27:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] chain of trust Date: Wed, 13 Nov 2002 11:27:02 +0200 Message-ID: Thread-Topic: [NSIS] chain of trust Thread-Index: AcKK9IIzZtA8+xEfQeWR553owPiueAAAf/hg To: , , Cc: , X-OriginalArrivalTime: 13 Nov 2002 09:27:02.0740 (UTC) FILETIME=[D30FA140:01C28AF6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAD9Rpv15697 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hannes, Some comments: > - a signaling protocol requires intermediate nodes to inspect, modify and > add message parts. hence only some non-mutuable fields can be protected or > incremental protection. the meaning for an end host might be questionable. What this means is that the signaling header may need to be unprotected, while the payload be protected. > - protocol operations like proxying might require some sort of delegation. Proxying is officially (or at least unofficially) discouraged by the Secuirty Area. > - applying end-to-end security between two arbitrary hosts might be a > deployment problem in general Can you suggest why? > if there are some objects which are only relevant for end hosts (and not for > intermediate nodes at all) then why is it necessary to ship them with a > signaling protocol. The above statement confuses me - is your question this: " ... necessary to ship them with a hop-by-hop signaling protocol." John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 05:09: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 FAA26416 for ; Wed, 13 Nov 2002 05:09:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADABOY18193 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 05:11: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 gADABLv18167; Wed, 13 Nov 2002 05:11: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 gADAA1v18143 for ; Wed, 13 Nov 2002 05:10:01 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26405 for ; Wed, 13 Nov 2002 05:07:25 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gADA9wY09657; Wed, 13 Nov 2002 11:09:58 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gADA9wB22827; Wed, 13 Nov 2002 11:09:58 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: , , Cc: , Subject: RE: [NSIS] chain of trust Date: Wed, 13 Nov 2002 11:10:40 +0100 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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi john. thanks for talking to the area directors to capture their view. please see my comments inline: > Hannes, > > Some comments: > > > - a signaling protocol requires intermediate nodes to inspect, > modify and > > add message parts. hence only some non-mutuable fields can be > protected or > > incremental protection. the meaning for an end host might be > questionable. > > What this means is that the signaling header may need to be > unprotected, while > the payload be protected. it depends what payload you are referring to: - flow identifier (no) - lifetime (no) - policy object (no) - local objects (no) - something like a adspec object (no) - qos parameters (don't know / might also be known to both end points) for nat/firewall traversal i am not really sure what end-to-end actually means. is the firewall the end or the host to which the messages are addressed. i will look at rsvp to see how many parameters are possible candidates for end-to-end protection. (probably not a long list). question to bob: has someone ever suggested end-to-end security protection for rsvp? my conclusion: more investigation is required in this area. > > > - protocol operations like proxying might require some sort of > delegation. > > Proxying is officially (or at least unofficially) discouraged by > the Secuirty > Area. interesting to hear this. is this also reflected in the framework document? avoiding proxy operation also means that something like local reservations (where the end point is unkown) is also not allowed. this might have some implications for mobility. another example: in some architectures the end host communicates his qos parameters using a link layer protocol. signaling at the ip layer then starts somewhere at the access network. this is also a proxy operation. > > > - applying end-to-end security between two arbitrary hosts might be a > > deployment problem in general > > Can you suggest why? key management. many of us followed the mobile ipv6 binding update discussions. > > > if there are some objects which are only relevant for end hosts > (and not for > > intermediate nodes at all) then why is it necessary to ship them with a > > signaling protocol. > > The above statement confuses me - is your question this: > > " ... necessary to ship them with a hop-by-hop signaling protocol." for example: someone suggested to negotiate parameter to determine who has to pay for a reservation within a signaling protocol. this negotiation is purely end-to-end. hence there is a question why it has to be piggybacked on top of a signaling protocol like nsis. ciao hannes > > John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 05:09: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 FAA26429 for ; Wed, 13 Nov 2002 05:09:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADABPe18205 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 05:11: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 gADABNv18182; Wed, 13 Nov 2002 05:11:23 -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 gADAA1v18141 for ; Wed, 13 Nov 2002 05:10:01 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26404 for ; Wed, 13 Nov 2002 05:07:25 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gADA9wY09651; Wed, 13 Nov 2002 11:09:58 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gADA9vB22808; Wed, 13 Nov 2002 11:09:57 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: , , Cc: , Subject: RE: [NSIS] Key management - Nat involvement Date: Wed, 13 Nov 2002 11:10:40 +0100 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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi john. my question to a requirement for end-to-end security is : is this a - "would be nice to have" - "must be there" - "the protocol should support it if the security associations (for the two end hosts) are available?" ciao hannes > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, November 13, 2002 10:17 AM > To: Hannes.Tschofenig@siemens.com; mshore@cisco.com; braden@ISI.EDU > Cc: mat@cisco.com; nsis@ietf.org > Subject: RE: [NSIS] Key management - Nat involvement > > > Hi Hannes, > > > why do you think that a nat might be able to get the key material of a > > different nat? > > > > sender <--------> Nat1 <------------> Nat2 <-----------> receiver > > > > if peer-to-peer security is used then a signaling message is secured > > between sender and nat1 and again secured between the two nats. > if you only > > use peer-to-peer security then the sender trusts the nodes > along the path to > > work in the expected way. a corrupted nat might for example > create a wrong > > nat binding and you would not be able to detect it. but this > results from > > the way how signaling protocols work. > > So, the Security Area has gone on record that this sort of transitive > trust is inherently insecure, as the sender has know knowledge of the > entities along the path, therefore is in no possition to assess the > security risk. As a corrupted or compromised node could inflict much > damage, as the sender assumes that signaling is secured. > > Therefore, we cannot reply on peer-to-peer security, but have to > be able to > have an end-to-end mechanism. > > John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 06:08: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 GAA27463 for ; Wed, 13 Nov 2002 06:08:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADBAJr21580 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 06:10:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADBAHv21569; Wed, 13 Nov 2002 06:10: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 gADB95v21511 for ; Wed, 13 Nov 2002 06:09:05 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27423 for ; Wed, 13 Nov 2002 06:06:29 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gADB9fB10697 for ; Wed, 13 Nov 2002 13:09:41 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Nov 2002 13:09:02 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 13 Nov 2002 13:09:01 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 13 Nov 2002 13:09:00 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 13 Nov 2002 13:09:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Key management - Nat involvement Date: Wed, 13 Nov 2002 13:08:59 +0200 Message-ID: Thread-Topic: [NSIS] Key management - Nat involvement Thread-Index: AcKK/NnTGxHrtCZjRWq2SCydYSKDtQAB/x6w To: , , Cc: , X-OriginalArrivalTime: 13 Nov 2002 11:09:00.0501 (UTC) FILETIME=[1187E050:01C28B05] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gADB96v21512 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Hannes, > my question to a requirement for end-to-end security is : > is this a > - "would be nice to have" > - "must be there" > - "the protocol should support it if the security > associations (for the two end hosts) are available?" For the requirement doc, the level I would suggest would be: It MUST be able to be possible to secure the signaling end-to-end at the appropriate layer. What I mean, is that we should analyze the 2 layer split and see what needs to be protected & at what level. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 06:12: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 GAA27562 for ; Wed, 13 Nov 2002 06:12:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADBEIH21710 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 06:14: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 gADBEFv21703; Wed, 13 Nov 2002 06:14: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 gADBDhv21680 for ; Wed, 13 Nov 2002 06:13:43 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27521 for ; Wed, 13 Nov 2002 06:11:06 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gADBEJB14546 for ; Wed, 13 Nov 2002 13:14:19 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Nov 2002 13:13:40 +0200 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 13 Nov 2002 13:13:30 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 13 Nov 2002 13:13:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] chain of trust Date: Wed, 13 Nov 2002 13:13:29 +0200 Message-ID: Thread-Topic: [NSIS] chain of trust Thread-Index: AcKK/Q7OkdHAGdvVSxS06b+Eufal4AACAekQ To: , , Cc: , X-OriginalArrivalTime: 13 Nov 2002 11:13:30.0380 (UTC) FILETIME=[B26424C0:01C28B05] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gADBDhv21681 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Hannes, > it depends what payload you are referring to: > - flow identifier (no) > - lifetime (no) > - policy object (no) > - local objects (no) > - something like a adspec object (no) > - qos parameters (don't know / might also be known to both end points) Agreed. Some of these may need to be readable by intermediate nodes, I am not sure which need to be mutable. > for nat/firewall traversal i am not really sure what end-to-end actually > means. is the firewall the end or the host to which the messages are > addressed. Well, if you are signaling the NAT (for example) I see this as the endpoint. > i will look at rsvp to see how many parameters are possible candidates for > end-to-end protection. (probably not a long list). question to bob: has > someone ever suggested end-to-end security protection for rsvp? > > my conclusion: more investigation is required in this area. Most definately. > > > - protocol operations like proxying might require some sort of > > delegation. > > > > Proxying is officially (or at least unofficially) discouraged by > > the Secuirty Area. > > interesting to hear this. is this also reflected in the framework document? > avoiding proxy operation also means that something like local reservations > (where the end point is unkown) is also not allowed. this might have some > implications for mobility. It is not currently in the framework. I would like to ask a security person to look at it an recomend it. > another example: > in some architectures the end host communicates his qos > parameters using a > link layer protocol. signaling at the ip layer then starts > somewhere at the access network. this is also a proxy operation. It is a proxy of a sort, but I would not call it a layer 3 proxy. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 08:00: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 IAA29366 for ; Wed, 13 Nov 2002 08:00:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADD2G427133 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 08:02: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 gADD2Dv27124; Wed, 13 Nov 2002 08:02: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 gADD1Gv27083 for ; Wed, 13 Nov 2002 08:01:16 -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 HAA29344 for ; Wed, 13 Nov 2002 07:58: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-3.cisco.com (8.12.2/8.12.2) with ESMTP id gADD13aE008304; Wed, 13 Nov 2002 05:01:03 -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 AAT98799; Wed, 13 Nov 2002 04:56:32 -0800 (PST) Message-Id: <200211131256.AAT98799@mira-sjc5-4.cisco.com> To: Hannes.Tschofenig@siemens.com cc: "Bob Braden" , mat@cisco.com, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Key management - Nat involvement In-Reply-To: Message from "Hannes Tschofenig" of "Wed, 13 Nov 2002 10:10:27 +0100." Date: Wed, 13 Nov 2002 08:01:11 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > why do you think that a nat might be able to get the key material of a > different nat? > > sender <--------> Nat1 <------------> Nat2 <-----------> receiver We were talking specifically about transitive trust and hop-by-hop (at the NSIS transport layer) security mechanisms. If we rely on the latter for securing key exchanges between the sender and Nat2 in order to support end-to-middle security at the application layer between the sender and Nat2, the keying material in flight will decrypted and re-encrypted at Nat1. That's not really very secure, and in environments where Nat1 and Nat2 are under different administrative control it's quite risky. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 08:32: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 IAA00265 for ; Wed, 13 Nov 2002 08:32:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADDYTP29123 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 08:34: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 gADDYNv29111; Wed, 13 Nov 2002 08:34:23 -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 gADDXtv29094 for ; Wed, 13 Nov 2002 08:33:55 -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 IAA00233 for ; Wed, 13 Nov 2002 08:31:19 -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 gADDXqIX003936; Wed, 13 Nov 2002 05:33:52 -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 AAT99304; Wed, 13 Nov 2002 05:29:11 -0800 (PST) Message-Id: <200211131329.AAT99304@mira-sjc5-4.cisco.com> To: Hannes.Tschofenig@siemens.com cc: "Bob Braden" , mat@cisco.com, nsis@ietf.org From: Melinda Shore In-Reply-To: Message from "Hannes Tschofenig" of "Wed, 13 Nov 2002 10:10:27 +0100." Date: Wed, 13 Nov 2002 08:33:50 -0500 Subject: [NSIS] Re: chain of trust Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > - a signaling protocol requires intermediate nodes to inspect, modify and > add message parts. hence only some non-mutuable fields can be protected or > incremental protection. the meaning for an end host might be questionable. There is at least one case under consideration (NAT) where a box in the middle of a network *must* authenticate itself to the signaling initiator (there may be some issues with security gateway discovery, as well - I need to think about that some more). That has to be protected end-to-end between the NAT and the signaling initiator. Now, it may be possible (probable, even) that we'd have to set up an additional secure channel between them to do this, but I do think it's some clear that there are some security problems here that can't be solved with hop-by-hop protection alone. > - applying end-to-end security between two arbitrary hosts might be a > deployment problem in general Applying hop-by-hop security between two arbitrary devices isn't going to be any easier. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 08:40: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 IAA00477 for ; Wed, 13 Nov 2002 08:40:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADDg7530072 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 08:42: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 gADDg4v30065; Wed, 13 Nov 2002 08:42: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 gADDemv29988 for ; Wed, 13 Nov 2002 08:40:48 -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 IAA00427 for ; Wed, 13 Nov 2002 08:38: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-2.cisco.com (8.12.2/8.12.2) with ESMTP id gADDedep021395; Wed, 13 Nov 2002 05:40:39 -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 AAT99427; Wed, 13 Nov 2002 05:36:05 -0800 (PST) Message-Id: <200211131336.AAT99427@mira-sjc5-4.cisco.com> To: john.loughney@nokia.com cc: Hannes.Tschofenig@siemens.com, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] chain of trust In-Reply-To: Message from of "Wed, 13 Nov 2002 13:13:29 +0200." Date: Wed, 13 Nov 2002 08:40:44 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > Well, if you are signaling the NAT (for example) I see this as the = > endpoint. It depends. For signaling purposes it's not an endpoint, it's just another NSIS forwarder with peculiar properties. For the purposes of securing the operation, however, it's an endpoint in that unlike a router that's being participating in QoS signaling, the NAT needs to authenticate itself to the sender, which is an end-to-end operation between the NAT and the sender. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 09:39: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 JAA02620 for ; Wed, 13 Nov 2002 09:39:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADEfdQ01719 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 09:41:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADEfZv01712; Wed, 13 Nov 2002 09:41:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADEexv01685 for ; Wed, 13 Nov 2002 09:40:59 -0500 Received: from thoth.sbs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02599 for ; Wed, 13 Nov 2002 09:38:22 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id gADEesh28321; Wed, 13 Nov 2002 15:40:54 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gADEesB04492; Wed, 13 Nov 2002 15:40:54 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Melinda Shore" Cc: "Bob Braden" , , Subject: RE: [NSIS] Key management - Nat involvement Date: Wed, 13 Nov 2002 15:41:34 +0100 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) In-Reply-To: <200211131256.AAT98799@mira-sjc5-4.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi melinda! please see my comments inline: > > > why do you think that a nat might be able to get the key material of a > > different nat? > > > > sender <--------> Nat1 <------------> Nat2 <-----------> receiver > > We were talking specifically about transitive trust and > hop-by-hop (at the NSIS transport layer) security > mechanisms. If we rely on the latter for securing key > exchanges between the sender and Nat2 in order to support > end-to-middle security at the application layer between the > sender and Nat2, the keying material in flight will > decrypted and re-encrypted at Nat1. if you perform end-to-middle authentication and key agreement then you nat1 does not learn the key. if you provide end-to-middle authentication you still have to provide peer-to-peer protection. end-to-middle is only an additional protection for some specific objects. you need to know to whom you send these protected objects. if you apply - a digital signature for verification at nat2 then nat1 does not learn any key - a keyed message digest (based on a preshared secret) then nat1 does not learn any key - a key exchange betwen sender and nat2 then nat1 does not learn they key. as a more concrete example: the rsvp integrity object would provide peer-to-peer protection. if you would include a service ticket for nat2 in the policy data object then this would be an end-to-peer protection. based on the security of kerberos nat1 would not be able to decrypt the ticket to receive the session key. > That's not really very > secure, and in environments where Nat1 and Nat2 are under > different administrative control it's quite risky. ciao hannes > > Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 09:55: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 JAA03433 for ; Wed, 13 Nov 2002 09:55:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADEvap02550 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 09:57: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 gADEvYv02508; Wed, 13 Nov 2002 09:57: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 gADErcv02250 for ; Wed, 13 Nov 2002 09:53:38 -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 JAA03193 for ; Wed, 13 Nov 2002 09:51: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-1.cisco.com (8.12.2/8.12.2) with ESMTP id gADErYIX007274; Wed, 13 Nov 2002 06:53: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 AAU00778; Wed, 13 Nov 2002 06:48:53 -0800 (PST) Message-Id: <200211131448.AAU00778@mira-sjc5-4.cisco.com> To: Hannes.Tschofenig@siemens.com cc: "Bob Braden" , mat@cisco.com, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Key management - Nat involvement In-Reply-To: Message from "Hannes Tschofenig" of "Wed, 13 Nov 2002 15:41:34 +0100." Date: Wed, 13 Nov 2002 09:53:32 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > if you perform end-to-middle authentication and key agreement then you nat1 > does not learn the key. That's not necessarily true. If we rely on hop-by-hop security provided by the NSIS transport layer for protecting the key exchange, it most certainly will learn the key. > if you provide end-to-middle authentication you still have to provide > peer-to-peer protection. Yes, but it's not sufficient to protect a key exchange between the sender and Nat2. Unless we're using pre-shared keys (and I think that's a baaaaaad way to key this) we're going to have to do this in the NSIS application and we're almost certainly going to have to do it out-of-band. This is one case, and I think it's not an isolated one, where you cannot safely assume that trust is transive and where hop-by-hop security is inadequate for protecting signaling. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 09:58: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 JAA03633 for ; Wed, 13 Nov 2002 09:58:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADF0CX02938 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 10:00: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 gADF05v02814; Wed, 13 Nov 2002 10:00: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 gADEvAv02456 for ; Wed, 13 Nov 2002 09:57:10 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03374 for ; Wed, 13 Nov 2002 09:54:33 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id gADEv5N05720; Wed, 13 Nov 2002 15:57:06 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gADEv4B11819; Wed, 13 Nov 2002 15:57:05 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Melinda Shore" Cc: "Bob Braden" , , Date: Wed, 13 Nov 2002 15:57:45 +0100 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) In-Reply-To: <200211131329.AAT99304@mira-sjc5-4.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [NSIS] RE: chain of trust Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi melinda! please see my comments inline: > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, November 13, 2002 2:34 PM > To: Hannes.Tschofenig@siemens.com > Cc: Bob Braden; mat@cisco.com; nsis@ietf.org > Subject: Re: chain of trust > > > > - a signaling protocol requires intermediate nodes to inspect, > modify and > > add message parts. hence only some non-mutuable fields can be > protected or > > incremental protection. the meaning for an end host might be > questionable. > > There is at least one case under consideration (NAT) where a > box in the middle of a network *must* authenticate itself to > the signaling initiator (there may be some issues with > security gateway discovery, as well - I need to think about > that some more). That has to be protected end-to-end > between the NAT and the signaling initiator. i consider end-to-end as a protection between a nsis initator and a nsis responder. for end-to-end signaling these are usually two end hosts. nsis iniator to a nat box would then be a end-to-middle authentication. > Now, it may be > possible (probable, even) that we'd have to set up an > additional secure channel between them to do this, but I do > think it's some clear that there are some security problems > here that can't be solved with hop-by-hop protection alone. i agree with you. this is why i argue that you need some end-to-middle protection in addition to peer-to-peer security. this peer-to-peer security might also use different mechanisms. > > > - applying end-to-end security between two arbitrary hosts might be a > > deployment problem in general > > Applying hop-by-hop security between two arbitrary devices > isn't going to be any easier. i personally think that peer-to-peer protection is much easier than end-to-end protection for the following reasons: - intra-domain communication if you setup your network you exactly know which routers support nsis and could possibly communicate with each other. in this case even pre-shared secrets might be used (as rsvp does it today). you can take a look at mpls networks (and signaling with rsvp-te) to see how the security works and how difficult it is to setup keys between two adjacent routers. - first-peer communication this communication heavily depends on the scenario. for enterprise networks this is not too difficult because of the higher degree and basically no mobility. rsvp proposes mechanisms which work. windows 2000 used kerberos in rsvp for this purpose for their rsvp implementation. packetcable people use the integrity object. in the mobile case things are more difficult. some working groups which deal with this issue is ipsra and pana. especially pana tries to provide a secure network access. seamoby might also be relevant (and mobileip) since they also assume something going on between the mobile node and the access router. - inter-domain communication inter-domain qos signaling is an on-going work. security protection might depend on whether nsis signaling messages are transparent within the core network. if there is no nsis node in the core network then the signaling messages are effectively processed at the edges of the access networks only. in this case there might be a concern regarding key management. but the same concern might then also be applicable to aaa communication. the accouting architecture might in general have an impact. ciao hannes > > Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 09:58: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 JAA03635 for ; Wed, 13 Nov 2002 09:58:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADF0CZ02950 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 10:00: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 gADF06v02829; Wed, 13 Nov 2002 10:00: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 gADEvBv02460 for ; Wed, 13 Nov 2002 09:57:11 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03375 for ; Wed, 13 Nov 2002 09:54:33 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gADEv6Y11096; Wed, 13 Nov 2002 15:57:06 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gADEv5B11862; Wed, 13 Nov 2002 15:57:06 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Melinda Shore" , Cc: Subject: RE: [NSIS] chain of trust Date: Wed, 13 Nov 2002 15:57:46 +0100 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) In-Reply-To: <200211131336.AAT99427@mira-sjc5-4.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi melinda! i see that an end host (nsis initiator) has to authenticate itself to a firewall in many cases. but why should a nat authenticate itself to the signaling initator? why is it not sufficient to have authentication of the nat to its nsis peer? ciao hannes > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, November 13, 2002 2:41 PM > To: john.loughney@nokia.com > Cc: Hannes.Tschofenig@siemens.com; nsis@ietf.org > Subject: Re: [NSIS] chain of trust > > > > Well, if you are signaling the NAT (for example) I see this as the = > > endpoint. > > It depends. For signaling purposes it's not an endpoint, > it's just another NSIS forwarder with peculiar properties. > For the purposes of securing the operation, however, it's an > endpoint in that unlike a router that's being participating > in QoS signaling, the NAT needs to authenticate itself to > the sender, which is an end-to-end operation between the NAT > and the sender. > > Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 10:14: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 KAA04283 for ; Wed, 13 Nov 2002 10:14:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADFGEm04420 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 10:16: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 gADFG9v04391; Wed, 13 Nov 2002 10:16: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 gADFFhv04347 for ; Wed, 13 Nov 2002 10:15:43 -0500 Received: from thoth.sbs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04211 for ; Wed, 13 Nov 2002 10:13:06 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id gADFFch25231; Wed, 13 Nov 2002 16:15:38 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gADFFcB27714; Wed, 13 Nov 2002 16:15:38 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Melinda Shore" Cc: "Bob Braden" , , Subject: RE: [NSIS] Key management - Nat involvement Date: Wed, 13 Nov 2002 16:16:18 +0100 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) In-Reply-To: <200211131448.AAU00778@mira-sjc5-4.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi melinda! please see my comments inline: > > if you perform end-to-middle authentication and key agreement > then you nat1 > > does not learn the key. > > That's not necessarily true. If we rely on hop-by-hop > security provided by the NSIS transport layer for protecting > the key exchange, it most certainly will learn the key. this is the place where concrete examples are useful: - if you run ike/kink/tls between two nodes then a third node should learn the key. (except if you send the key to him). - if you have hop-by-hop protection and additionally a rsvp policy object (with a kerberos ticket in it) then you do not allow other nodes to learn the key. an other example: cms can be used for diameter to transport session keys between a home aaa server to the aaa attendant. these keys are not revealed to the intermediate aaa server. still there is security protection between the aaa servers in addition to the cms mechanism. i guess (and hope) that we do not want to invent a new nsis key exchange protocol which uses hop-by-hop security to transport keying material. > > > if you provide end-to-middle authentication you still have to provide > > peer-to-peer protection. > > Yes, but it's not sufficient to protect a key exchange > between the sender and Nat2. Unless we're using pre-shared > keys (and I think that's a baaaaaad way to key this) we're > going to have to do this in the NSIS application and we're > almost certainly going to have to do it out-of-band. an example: you can use nsis to transport a cms object. cms allows authentication and key transport/key agreement. it allows to protect messages with symmetric and asymmetric mechanisms. if you have configured a pre-shared key (or exchanged public keys/certificates) out-of-band then this is great. you can immediately use them. in some cases you might have some pre-shared secrets or use session keys with a security mechanism. i would not generally argue that these keys are bad. in some cases they might be quite useful (for example: if you have already established a security association). This > is one case, and I think it's not an isolated one, where you > cannot safely assume that trust is transive and where > hop-by-hop security is inadequate for protecting signaling. this is true. that is the reason why i raised the end-to-middle discussion. also rsvp added it later and it seems to be a useful concept. it might require some rework (by using existing mechanisms) to incorporate recent developments. ciao hannes > > Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 10:35: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 KAA05008 for ; Wed, 13 Nov 2002 10:35:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADFbAY05827 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 10:37:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADFb8v05747; Wed, 13 Nov 2002 10:37: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 gADFalv05511 for ; Wed, 13 Nov 2002 10:36:47 -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 KAA04959 for ; Wed, 13 Nov 2002 10:34:09 -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 gADFaaep006670; Wed, 13 Nov 2002 07:36:36 -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 AAU01746; Wed, 13 Nov 2002 07:32:02 -0800 (PST) Message-Id: <200211131532.AAU01746@mira-sjc5-4.cisco.com> To: Hannes.Tschofenig@siemens.com cc: "Bob Braden" , mat@cisco.com, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] Key management - Nat involvement In-Reply-To: Message from "Hannes Tschofenig" of "Wed, 13 Nov 2002 16:16:18 +0100." Date: Wed, 13 Nov 2002 10:36:41 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > - if you run ike/kink/tls between two nodes then a third node should learn > the key. (except if you send the key to him). Do you mean "should not learn?" Anyway, this is true, but those are all out-of-band. If we go back to the original proposal, that hop-by-hop security should be adequate because we can rely on the transitivity of trust, we can find examples where it's not true and where we would need additional mechanism. That's all I'm trying to say, and I'm not proposing inventing anything. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 11:30: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 LAA07272 for ; Wed, 13 Nov 2002 11:30:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADGWI010404 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 11:32: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 gADGWGv10398; Wed, 13 Nov 2002 11:32: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 gADGVav10374 for ; Wed, 13 Nov 2002 11:31:36 -0500 Received: from thoth.sbs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07241 for ; Wed, 13 Nov 2002 11:28:57 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id gADGVVh15866; Wed, 13 Nov 2002 17:31:31 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gADGVVB29646; Wed, 13 Nov 2002 17:31:31 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Melinda Shore" Cc: "Bob Braden" , , Subject: RE: [NSIS] Key management - Nat involvement Date: Wed, 13 Nov 2002 17:32:11 +0100 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) In-Reply-To: <200211131532.AAU01746@mira-sjc5-4.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi melinda! > > - if you run ike/kink/tls between two nodes then a third node > should learn > > the key. (except if you send the key to him). > > Do you mean "should not learn?" capture, retrieve, obtain > Anyway, this is true, but > those are all out-of-band. do you classify the rsvp policy object type of mechanism as out-of-band? > If we go back to the original > proposal, that hop-by-hop security should be adequate > because we can rely on the transitivity of trust, we can > find examples where it's not true and where we would need > additional mechanism. That's all I'm trying to say, and I'm > not proposing inventing anything. i fully agree with you that peer-to-peer security is not sufficient for all scenarios. sometimes end-to-middle (or also middle-to-middle) might be required (there are example especially in the midcom area). ciao hannes > > Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 12:41: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 MAA09974 for ; Wed, 13 Nov 2002 12:41:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADHhKi16553 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 12:43: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 gADHhIv16534; Wed, 13 Nov 2002 12:43: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 gADHgHv16462 for ; Wed, 13 Nov 2002 12:42:17 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09866 for ; Wed, 13 Nov 2002 12:39:38 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gADHgBY10736; Wed, 13 Nov 2002 18:42:11 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail1.siemens.de (8.11.6/8.11.6) with SMTP id gADHgBB26929; Wed, 13 Nov 2002 18:42:11 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Melinda Shore" Cc: "Bob Braden" , , Subject: RE: [NSIS] Key management - Nat involvement Date: Wed, 13 Nov 2002 18:42:51 +0100 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) In-Reply-To: <200211131532.AAU01746@mira-sjc5-4.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi melinda! > > - if you run ike/kink/tls between two nodes then a third node > should learn > > the key. (except if you send the key to him). > > Do you mean "should not learn?" yes - true (=> not learn). ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 14:35: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 OAA14343 for ; Wed, 13 Nov 2002 14:35:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADJbLk24810 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 14:37:21 -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 gADJbJv24780; Wed, 13 Nov 2002 14:37: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 gADJaDv24231 for ; Wed, 13 Nov 2002 14:36:13 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14269 for ; Wed, 13 Nov 2002 14:33:33 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gADJa6a13426; Wed, 13 Nov 2002 11:36:06 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id TAA08169; Wed, 13 Nov 2002 19:36:06 GMT Date: Wed, 13 Nov 2002 19:36:06 GMT Message-Id: <200211131936.TAA08169@gra.isi.edu> To: nsis@ietf.org Cc: braden@ISI.EDU X-Sun-Charset: US-ASCII Subject: [NSIS] General comments on draft-ietf-nsis-fw-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , I finally found time to comment on the Framework draft. Sorry this comes so late. A separate message contains interleaved detailed comments, issues, questions, and disagreements. This message distills out some general comments. The Framework document represents a substantial body of work with much to recommend it. I know from experience how much work is represented here, and the authors deserve our praise and thanks. However, I also believe that considerable more work will be needed. First, a somewhat philosophical comment. My most general uneasiness with the present document is that it seems at times to float in a void. It seems a bit too top-down in flavor at times, without enough grounding in the real Internet issues. This gets better through the document, so that I generally liked sections 4, 5, and 6 much better than the eaerlier sections. It also seems a bit disconnected from the significant previous history of Internet signaling. Many of the technical issues of Internet signaling have in fact been explored in the IETF, principally by the RSVP working group (although not all of the conclusions made it into the existing RSVP v1 RFCs). Many readers will be familiar with at least the general concepts of RSVP, and it would be very helpful if the document was explicit, at least in a parenthetical way, about places where NSIS is taking a new tack, as well as places where it is covering the same ground. In a few places, using existing terminology where it fits would also be helpful. Now more specific general comments ;-) 1. I believe that the document would gain increased depth and credibility if it had a few more references to important and relevant academic papers. Particular examples might include YESSIR, Lixia's multi-level model, or (a small selection out of the corpus of) papers about mobile resource reservations. 2. There is a lot of good material and specific discussion, but there is some redundancy. It probably needs a serious hack with a text editor, moving blocks of text around and deleting redundant material. (see detailed comment message for examples.) 3. I would like to suggest that the only occurrence of the 4-letter term "NSIS" in this document should be in the combination "NSIS Working Group". All other occurrences of NSIS should be replaced by something else ... e.g., "Internet signaling" or "signaling" or ... whatever works in the particular context. Another useful term is "suite", as in a "suite of signaling protocols". Curiously, the word "node" almost never occurs in this document, yet it is fundamental. Signaling can be described abstractly, but that has to map into real messages sent between real nodes -- end systems, routers, and middleboxes. This may be just a stylistic thing. 4. The document tends to say, "Oh, by the way, this is not *just* about QoS", and then shortly falls into QoS-oriented terminology. I think this is the wrong orientation. It should rather be: "This is about all forms of path-related Internet signaling, such as QoS setup and control of middleboxes." A deeper consequence of this is the need to be quite precise about terminology, to make sure it is sufficiently general. What is the purpose of "signaling"? I generally use the Computer Sciency phrase, "to establish state in network nodes". The document often uses the term "resource request" for roughly the same concept (though it is not consistent.) At first I thought "resource request" should be replaced because it is too QoS-specific. However, it seems more in keeping with the existing document to simply define "resource request" in a general way as equivalent to setting up state, using a very general notion of what we mean by "resource". I think this can be made to work, but it needs a careful paragraph in the Introduction and strict care to always use this term. You will find a number of detailed suggested changes in this direction in my detailed comments. 5. At many points, the Framework document seems to assume a simplistic model of resource reservation -- that it is necessarily one-pass and can be achieved by a one-way flow of signaling packets along the data flow path. This omits the potentially important cases that require two-pass algorithms, or those that use one-pass-with-advertising (e.g., the IntServ Guaranteed service.) The WG should beware of simplistic assumptions. This shows up most directly in the terms NI and NR, whose semantics are sometimes confusing. Of course, *I* prefer the abstractions p-src and p-dest that I introduced in my 2level document ;-), but perhaps NI and NR can be made to work. However, that will require careful definition and usage. For example, RSVP v1 depends upon signaling in both directions, using both Path and Resv messages. So, for RSVP v1, both sender and receiver act as both NI and NR. Some of the discussion does not seem to encompass this generality. 6. The fundamental architectural picture in Figs 1 and 4 seems at first blush to be obvious, but the more I think about it, the more uncertain I am. The idea of a "co-located NI&NF" seems to conceptually define what you expect to be in an end system doing QoS signaling using the new protocol (and indeed that is exactly what RSVP v1 assumed). In particular, an Internet end system has to have at least a primitive routing/forwarding function, because it may be multihomed and/or have multiple first-hop routers. Also, for QoS setup, at least, it is generally necessary to have an (inner-)RMF in the end system as well as in the routers. (as shown in figure 9, which contradicts Figure 1!) These considerations probably hold even if the NI is not an end system. In fact, now that I think of it, it seems that there "co-located NI&NF" will be the normal case, except when a proxy is the NI. Iin practice the NI and NF functions will hopefully be only a single protocol entity in the end system. You can DESCRIBE it logically as two connected conceptual boxes, but this may not be very helpful to the implementor or in detailed design. In other words, the seemingly plausible picture conceals a deep issue of modularity and interface placement. Even if we decide that the figures as drawn at the best model, some discussion is needed about how this model maps into the real world. 7. The path-coupled/path-decoupled dichotomy is not all there is. Thinking about this space, I was led to introduce a different dichotomy, "path-related" vs. "path-unrelated". The NSIS WG is primarily focusing on path-related & path-coupled signaling, but some would like to also handle path-related & path-decoupled signaling. However, there is a 3rd class of signaling that has no direct relationship to any path; I called this path-decoupled. It might for example be used to configure routers in a domain. This is still signaling, but not the kind we intend to do in NSIS. 8. The text tends to imply the model of a signaling message passing from NI to NR through NFs undisturbed, rather like IP packets passing through routers. (See for example the first sentence of section 5.1) In some cases this may be the wrong conceptual model. In RSVP, signaling is best thought of as hop/hop; each hop propogates state in each direction, to keep certain invariants true. Also, refresh messages are generated independently and asyncronously at each hop. It is true that hop/hop action is forced by support for multicast, with its merging, so it may not be directly relevant to NSIS. However, there may be other signaling applications that will best be implemented as hop/hop signaling. 9. Sections 5.1 and 7.2 (which are somewhat redundant) seem foggy to me. For one thing, an RMF may be specific to one or more signaling applications, and there may be many distinct RMFs in a single node. Also, Figure 4 (which is repeated as Figure 7) and Figure 8 depict two quite different kinds to things [I would call them "entities", but you've used up that word ;-)], and it is not clear to me that you can usefully encompass both in a common abstraction. I see two kinds of things: an inner-RMF, which is the interface to the local node's I see "inner-RMFs" (Figs 4 & 7) that are local interfaces to the traffic control and admission control mechanisms of the forwarding plane. The WG should look into how an inner-RMF relates to the FORCES work of the IETF. Note that when an inner-RMF is a server, it may supply information to the NE as well as accept control state. Examples are admission control decisions and the Adspec machinery of RSVP v1. Then there are "outer-RMFs" (Figure 8), which seem to have quite different characteristics. This section to be an attempt to bring the bandwidth broker under the NSIS umbrella, but this may/may not fall into our chartered area. Finally, it is far from obvious to me that the NF/RMF interface corresponds to an SLA. _____________________________________ Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 14:49: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 OAA14872 for ; Wed, 13 Nov 2002 14:49:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gADJpB125628 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 14:51: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 gADJp8v25604; Wed, 13 Nov 2002 14:51: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 gADJo2v25481 for ; Wed, 13 Nov 2002 14:50:02 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14794 for ; Wed, 13 Nov 2002 14:47:23 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gADJnta23887; Wed, 13 Nov 2002 11:49:55 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id TAA08223; Wed, 13 Nov 2002 19:49:54 GMT Date: Wed, 13 Nov 2002 19:49:54 GMT Message-Id: <200211131949.TAA08223@gra.isi.edu> To: nsis@ietf.org, braden@ISI.EDU X-Sun-Charset: US-ASCII Subject: [NSIS] Re: Detailed comments on draft-ietf-nsis-fw-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , It turns out that my commented version is 130KB, so John L will probably kill it before it propogates. I put it on the web at www.isi.edu/~braden/nsis/comments_framework_draft01.txt Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 19:20: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 TAA22574 for ; Wed, 13 Nov 2002 19:20:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAE0MVZ09800 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 19:22: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 gAE0MSv09789; Wed, 13 Nov 2002 19:22: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 gAE0Lfv09760 for ; Wed, 13 Nov 2002 19:21:41 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22559 for ; Wed, 13 Nov 2002 19:18:57 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Nov 2002 00:21:31 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5E31@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Bob Braden , nsis@ietf.org Subject: RE: [NSIS] General comments on draft-ietf-nsis-fw-01.txt Date: Thu, 14 Nov 2002 00:21:20 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Bob, Thanks for the detailed review (when I get at it). I think 1/2/3/4/7/9 are all probably quite reasonable (and are basically presentation related). I think the point you raise in 6 is interesting, which I and others agonised a lot about in this and previous non-framework documents. Eventually I gave up worrying because I couldn't see a practical impact. If we can find one, it should help us work out which alternatives to emphasise. The point in 8 is partly related. I have generally come from a perspective of thinking that an internal node could do arbitrary violence to the messages (do we even assume it is the same signalling application protocol either side?) but maybe this doesn't come across (and quite possibly isn't what other people think). I think the most important point you raise is (5) - what message patterns we should support/assume. I'd really like to see some views about the range of options here. Cheers, Robert H. > -----Original Message----- > From: Bob Braden [mailto:braden@ISI.EDU] > Sent: 13 November 2002 20:36 > To: nsis@ietf.org > Cc: braden@ISI.EDU > Subject: [NSIS] General comments on draft-ietf-nsis-fw-01.txt > > > > I finally found time to comment on the Framework draft. Sorry this > comes so late. > > A separate message contains interleaved detailed comments, issues, > questions, and disagreements. This message distills out some general > comments. > > The Framework document represents a substantial body of work with much > to recommend it. I know from experience how much work is represented > here, and the authors deserve our praise and thanks. However, I also > believe that considerable more work will be needed. > > First, a somewhat philosophical comment. My most general uneasiness > with the present document is that it seems at times to float in a > void. It seems a bit too top-down in flavor at times, without enough > grounding in the real Internet issues. This gets better through the > document, so that I generally liked sections 4, 5, and 6 much better > than the eaerlier sections. It also seems a bit disconnected from the > significant previous history of Internet signaling. Many of the > technical issues of Internet signaling have in fact been explored in > the IETF, principally by the RSVP working group (although not all of > the conclusions made it into the existing RSVP v1 RFCs). > > Many readers will be familiar with at least the general concepts of > RSVP, and it would be very helpful if the document was explicit, at > least in a parenthetical way, about places where NSIS is taking a new > tack, as well as places where it is covering the same ground. > In a few > places, using existing terminology where it fits would also be > helpful. > > Now more specific general comments ;-) > > 1. I believe that the document would gain increased depth and > credibility if it had a few more references to important and > relevant academic papers. Particular examples might include > YESSIR, Lixia's multi-level model, or (a small selection out of > the corpus of) papers about mobile resource reservations. > > 2. There is a lot of good material and specific discussion, but there > is some redundancy. It probably needs a serious hack > with a text editor, moving blocks of text around and deleting > redundant material. (see detailed comment message for examples.) > > 3. I would like to suggest that the only occurrence of the 4-letter > term "NSIS" in this document should be in the combination > "NSIS Working Group". All other occurrences of NSIS should > be replaced by something else ... e.g., "Internet signaling" > or "signaling" or ... whatever works in the particular context. > > Another useful term is "suite", as in a "suite of signaling > protocols". > > Curiously, the word "node" almost never occurs in this document, > yet it is fundamental. Signaling can be described abstractly, > but that has to map into real messages sent between real > nodes -- end systems, routers, and middleboxes. This may be > just a stylistic thing. > > 4. The document tends to say, "Oh, by the way, this is not > *just* about > QoS", and then shortly falls into QoS-oriented terminology. > I think this is the wrong orientation. It should rather be: > "This is about all forms of path-related Internet signaling, > such as QoS setup and control of middleboxes." > > A deeper consequence of this is the need to be quite > precise about > terminology, to make sure it is sufficiently general. > > What is the purpose of "signaling"? I generally use the > Computer Sciency phrase, "to establish state in network > nodes". The document often uses the term "resource > request" for roughly the same concept (though it is not > consistent.) > > At first I thought "resource request" should be replaced > because it is too QoS-specific. However, it seems more in > keeping with the existing document to simply define "resource > request" in a general way as equivalent to setting up state, > using a very general notion of what we mean by "resource". I > think this can be made to work, but it needs a careful > paragraph in the Introduction and strict care to always use > this term. You will find a number of detailed suggested > changes in this direction in my detailed comments. > > 5. At many points, the Framework document seems to assume a simplistic > model of resource reservation -- that it is necessarily > one-pass and can be achieved by a one-way flow of signaling > packets along the data flow path. This omits the potentially > important cases that require two-pass algorithms, or those that > use one-pass-with-advertising (e.g., the IntServ Guaranteed > service.) The WG should beware of simplistic > assumptions. > > This shows up most directly in the terms NI and NR, whose > semantics are sometimes confusing. Of course, *I* prefer the > abstractions p-src and p-dest that I introduced in my 2level > document ;-), but perhaps NI and NR can be made to work. > However, that will require careful definition and usage. For > example, RSVP v1 depends upon signaling in both directions, > using both Path and Resv messages. So, for RSVP v1, both > sender and receiver act as both NI and NR. Some of the > discussion does not seem to encompass this generality. > > 6. The fundamental architectural picture in Figs 1 and 4 seems at > first blush to be obvious, but the more I think about it, > the more uncertain I am. > > The idea of a "co-located NI&NF" seems to conceptually define > what you expect to be in an end system doing QoS signaling > using the new protocol (and indeed that is exactly what RSVP v1 > assumed). In particular, an Internet end system has to have at > least a primitive routing/forwarding function, because it may > be multihomed and/or have multiple first-hop routers. Also, > for QoS setup, at least, it is generally necessary to have an > (inner-)RMF in the end system as well as in the routers. > (as shown in figure 9, which contradicts Figure 1!) > > These considerations probably hold even if the NI is not an > end system. In fact, now that I think of it, it seems that > there "co-located NI&NF" will be the normal case, except when > a proxy is the NI. > > Iin practice the NI and NF functions will hopefully be only a > single protocol entity in the end system. You can DESCRIBE it > logically as two connected conceptual boxes, but this may not > be very helpful to the implementor or in detailed design. In > other words, the seemingly plausible picture conceals a deep > issue of modularity and interface placement. > > Even if we decide that the figures as drawn at the best model, > some discussion is needed about how this model maps into the > real world. > > > 7. The path-coupled/path-decoupled dichotomy is not all there is. > > Thinking about this space, I was led to introduce a different > dichotomy, "path-related" vs. "path-unrelated". The NSIS > WG is primarily focusing on path-related & path-coupled > signaling, but some would like to also handle path-related & > path-decoupled signaling. However, there is a 3rd class > of signaling that has no direct relationship to any path; I > called this path-decoupled. It might for example be used to > configure routers in a domain. This is still signaling, but > not the kind we intend to do in NSIS. > > 8. The text tends to imply the model of a signaling message passing > from NI to NR through NFs undisturbed, rather like IP packets > passing through routers. (See for example the first sentence > of section 5.1) In some cases this may be the wrong > conceptual model. In RSVP, signaling is best thought of as > hop/hop; each hop propogates state in each direction, to keep > certain invariants true. Also, refresh messages are generated > independently and asyncronously at each hop. It is true that > hop/hop action is forced by support for multicast, with its > merging, so it may not be directly relevant to NSIS. However, > there may be other signaling applications that will best be > implemented as hop/hop signaling. > > 9. Sections 5.1 and 7.2 (which are somewhat redundant) seem > foggy to me. > For one thing, an RMF may be specific to one or more signaling > applications, and there may be many distinct RMFs in a single > node. > > Also, Figure 4 (which is repeated as Figure 7) and Figure 8 > depict two quite different kinds to things [I would call them > "entities", but you've used up that word ;-)], and it is not > clear to me that you can usefully encompass both in a common > abstraction. I see two kinds of things: an inner-RMF, which is > the interface to the local node's > > I see "inner-RMFs" (Figs 4 & 7) that are local interfaces to > the traffic control and admission control mechanisms of the > forwarding plane. The WG should look into how an inner-RMF > relates to the FORCES work of the IETF. > > Note that when an inner-RMF is a server, it may supply > information to the NE as well as accept control state. > Examples are admission control decisions and the Adspec > machinery of RSVP v1. > > Then there are "outer-RMFs" (Figure 8), which seem to have > quite different characteristics. This section to be an attempt > to bring the bandwidth broker under the NSIS umbrella, but > this may/may not fall into our chartered area. > > Finally, it is far from obvious to me that the NF/RMF interface > corresponds to an SLA. > _____________________________________ > Bob Braden > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 13 22:53: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 WAA26971 for ; Wed, 13 Nov 2002 22:53:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAE3tW121519 for nsis-archive@odin.ietf.org; Wed, 13 Nov 2002 22:55: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 gAE3tQv21501; Wed, 13 Nov 2002 22:55: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 gADJalv24257 for ; Wed, 13 Nov 2002 14:36:47 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14283 for ; Wed, 13 Nov 2002 14:33:59 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gADJaVa14623; Wed, 13 Nov 2002 11:36:31 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id TAA08172; Wed, 13 Nov 2002 19:36:31 GMT Date: Wed, 13 Nov 2002 19:36:31 GMT Message-Id: <200211131936.TAA08172@gra.isi.edu> To: nsis@ietf.org Cc: braden@ISI.EDU X-Sun-Charset: US-ASCII Subject: [NSIS] Detailed comments on draft-ietf-nsis-fw-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This message contains detailed comments on the Framework document. (To make John L happy, I tried to include suggested alternative text in places.) It accompanies an overview message that tries to give high-level comments. Specific suggested changes are indicated below the changed lines, with lines prefixed with "####". *> Document: draft-ietf-nsis-fw-01.txt *> Expires: May 2003 November 2002 *> *> *> Next Steps in Signaling: Framework *> *> Status of this Memo *> *> *> Abstract *> *> The NSIS working group is considering protocols for signaling for *> resources for a traffic flow along its path in the network. The *> requirements for such signaling are being developed in [2]; this (No references allowed in an Abstract) *> Internet Draft will propose a framework for such signaling. *> "architectural framework" would be a little less vague than simply "framework" here. *> This initial version provides a model of the entities that take part *> in the signaling. It discusses the considerations that must be taken *> into account in developing the framework, particularly the options *> for the structure of such a protocol, and the interactions between *> Finally, it includes background material on how NSIS could support *> particular signaling applications. *> *> It is expected that future versions of this document will distill *> these structural options into a concrete technical framework, and *> material on particular signaling applications and deployment *> scenarios will be moved into separate NSIS applicability statements. *> *> Conventions used in this document *> *> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", *> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this *> document are to be interpreted as described in RFC-2119 [3]. *> Since this document is not a formal specification, applicability words are not appropriate, and indeed none are used. Therefore the above paragraph should be deleted. *> Table of Contents *> ... *> *> *> 1. Introduction *> The following introductory paragraph is muddy in both terminology and style; the summary in the Abstract is cleaner and clearer. Suggest starting from the Abstract and expanding it. *> NSIS will work on signaling from an end point that follows a path *> through the net that is determined by layer 3 routing and is used to *> convey information to the devices the signals pass through - the *> signaling can, for example, install soft state in the devices it #### XXXX (I believe that "convey information" and "install state" are semantically equivalent.) *> passes through. A signaling end point could be a device along the *> path, which signals for a data flow that passes through it. *> *> *> The intention is to allow for the NSIS protocol to be deployed in *> different parts of the Internet, for different needs, without *> requiring a complete end-to-end deployment. *> *> There is no requirement that the per-flow information be QoS related. How about: The per-flow information might be related to QoS or to some other control function in routers and middleboxes along the path. *> NSIS should only worry about how to do the signaling - what the *> signaling conveys should be opaque to NSIS. This document discusses *> 'where' the signaling takes place, with some discussion on 'how' the *> signaling can be done. *> *> 1.1 Scope of the NSIS Framework ... *> *> *> *> *> 2. Terminology Putting this termonology section early makes it tough for the reader and certainly does not help her/him. These terms are all introduced and defined a bit later. Capsule summaries of their definitions here, besides being redundant, are without context and therefore hard to follow. I suggest moving this section to an Appendix for quick reference, or at least to the end of Section 3. *> *> Classifier - an entity which selects packets based on their contents *> according to defined rules. *> *> Interdomain traffic - Traffic that passes from one NSIS domain to *> another. *> *> NSIS Domain (ND) - Administrative domain where an NSIS protocol *> signals for a resource or set of resources. *> *> NSIS Entity (NE) - the function within a node which implements an *> NSIS protocol. In the case of path-coupled signaling, the NE will *> always be on the data path. *> *> NSIS Forwarder (NF) - NSIS Entity between a NI and NR which may *> interact with local resource management function (RMF). It also *> propagates NSIS signaling further through the network. *> *> NSIS Initiator (NI) - NSIS Entity that initiates NSIS signaling for a *> network resource. *> *> NSIS Responder (NR) - NSIS Entity that terminates NSIS signaling and *> can optionally interact with applications as well. *> *> NSIS Signaling Layer Protocol (NSLP) - generic term for an NSIS *> protocol component that supports a specific signaling application. *> See also section 3.1.3. *> *> NSIS Transport Layer Protocol (NTLP) - placeholder name for the NSIS *> protocol component that will support lower layer (signaling *> application independent) functions. See also section 3.1.3. *> *> Path-coupled signaling - a mode of signaling where the signaling *> messages follow a path that is tied to the data messages. See also *> section 3.2.1. *> *> Path-decoupled signaling - signaling with independent data and *> signaling paths. *> *> Peer determination - the act of locating and/or selecting which NSIS *> peer to carry out signaling exchanges with for a specific data flow. *> *> Peer relationship - signaling relationship between two adjacent NSIS *> entities (i.e. NEs with no other NEs between them). I found only 3 uses of "peer relationship" in the entire document. Is it useful to define it here? *> *> Receiver - the node in the network which is receiving the data *> packets in a flow. *> *> *> Hancock et al. Expires - May 2003 [Page 5] *> Next Steps in Signaling: Framework November 2002 *> *> Resource - something of value in a network infrastructure to which *> rules or policy criteria are first applied before access is granted. *> Examples of resources include the buffers in a router and bandwidth *> on an interface. This definition of "resource" needs more work. It seems too QoS-specific. Here is one suggestion, but I don't think this is the final word: Resource - something of value in a network infrastructure to which access is granted as the result of signaling. Examples of resources might include buffers in a router, bandwidth on an interface, and flow-specific access rights through a firewall. Signaled access to resources is generally restrained by policy control. *> *> Resource Management Function (RMF) - an abstract concept, *> representing the management of resources in a domain or a node. [note that RMF seems to not be an abstract concept in section 5.1] *> *> Sender - the node in the network which is sending the data packets in *> a flow. *> *> Service Level Agreement (SLA) - a service contract between a customer *> and a service provider that specifies the forwarding service a *> customer should receive. *> *> [NSIS] Signaling application - the purpose of the NSIS signaling: a *> service could be QoS management, firewall control, and so on. Totally *> distinct from any specific user application. *> *> Traffic characteristic - a description of the temporal behavior or a *> description of the attributes of a given traffic flow or traffic *> aggregate. *> *> Traffic flow - a stream of packets between two end-points that can be *> characterized in a certain way. Ambig. sentence. Also, I don't think you want the "traffic" qualifier. How about: Flow (or data flow) - a stream of packets, from sender to receiver, that is a distinguishable subset of the packet stream. Each flow is distinguished by some flow identification (section 4.5.1). *> *> 3. Overall Framework Structure *> *> 3.1 Basic Signaling Entities and Interfaces *> *> 3.1.1 NSIS Entities *> *> The NSIS protocol is intended to be used as a signaling control plane *> for the variety of network resources required for data traffic across *> the Internet. The most common NSIS signaling applications are QoS #### Possible signaling applications include control of QoS *> resources, firewalls and NATs resources, etc. The NSIS signaling *> itself does not depend on the signaling application it is used for *> but the information it carries does. This section discusses the basic *> signaling entities of the protocol as well as interfaces between *> them. *> *> We can identify three different roles in the NSIS signaling for *> resources: initiator, forwarder and responder. *> *> The NSIS Initiator (NI) is an entity that initiates NSIS signaling *> (request) for the network resource. The NSIS initiator can be (See my general comments about this definition... I have to struggle to believe it. It is NOT intuitive; consider RSVP v1.) *> triggered by the different "sources" - user applications, an instance *> of NSIS Forwarder, other protocols, network management etc. - that *> need network resources for a data flow. For the purpose of the NSIS *> discussion all these sources can be called "applications" (note that *> this is entirely distinct from the specific term "signaling *> application"). The NSIS initiator can provide feedback information to *> the triggering application in respect to the requested network *> resources. The NSIS initiator uses NSIS signaling to interact with *> other NSIS entities (NFs and NRs). *> *> The NSIS Forwarder (NF) is an entity that services NSIS resource *> requests from NSIS initiators and other NSIS forwarders. It may *> interact with local resource management function (RMF). How and if *> this interaction takes place depends on the deployed resource *> management mechanism and the specific role of the NF. The NSIS *> forwarder propagates NSIS signaling further through the network. *> *> The NSIS Responder (NR) is an entity that terminates NSIS signaling *> and can optionally interact with local applications as well e.g. for *> the purpose of notification when network resources get allocated etc. *> *> The signaling relationship between two NSIS entities (with no other *> NSIS entities between them) is called simply a 'peer relationship'. How about: Two NSIS entities that communicate directly are said to be in a 'peer relationship'. *> This concept might loosely be described as an 'NSIS hop'; however, *> there is no implication that it corresponds to a single IP hop. *> Either or both NEs might store some state information about the *> other, but there is no assumption that they establish a long-term *> signaling session between themselves. *> *> Figure 1 depicts simplified interactions/interfaces between NI, NFs *> and NR as well as local applications and RMFs. Note that the NI and *> NR could also interact with an RMF; additionally, this could be *> modeled as co-location of NI&NF and NR&NF. This distinction should \ (and perhaps common implementation) *> have no impact on the operation of the protocol. Also, there is no *> bar on placing an NI or NR in the interior of the network, to *> initiate and terminate NSIS signaling independently of the ultimate *> endpoints of the end to end flow, and NI and NR do not have to talk *> via intervening NFs. An example of NSIS being used in this way is *> given in section 7.5. *> *> *> +-----------+ +-----------+ *> |Application| |Application| *> +-----------+ +-----------+ *> ^ ^ *> | | *> | |____________| |____________| | *> V | | | | V *> +----+ +----+ +----+ +----+ *> | NI |==========| NF |=====....=====| NF |==========| NR | *> +----+ +----+ +----+ +----+ *> ^ ^ *> | | *> V V *> +----+ +----+ *> |RMF | | RMF| *> +----+ +----+ *> (See my general comment in other message.) *> *> =========== = NSIS signaling messages *> *> |_________| = Scope of single NSIS *> | | "peer relationship" *> *> Figure 1: Basic NI/NF/NR Relationships Much of this discussion is redundant with section 5.1, and section 7.2 adds a whole new dimension. Wouldn't it be better/clearer to simply omit the RMF from this particular early diagram?? *> *> 3.1.2 Placement of NSIS Entities *> *> The NI, NF and NR definitions do not make any assumptions about *> placements of NSIS signaling entities in respect to the particular *> part of the network or data-forwarding path. *> *> They can be located along the data path (hosts generating and *> receiving data flows, edge routers, intermediate routers etc.) but it *> may not be the only one desirable location. (This is OK if you make the following paragraph is part of the preceding paragraph). *> *> In some cases it is desired to be able to initiate and/or terminate *> NSIS signaling not from the end host that generates/receives the data *> flow, but from the some other entities on the network that can be *> called NSIS signaling application proxies. There could be various *> reasons for this: signaling on behalf of the end hosts that are not *> enabled with NSIS, consolidation of the customer accounting *> (authentication, authorization) in respect to consumed application *> and transport resources, security considerations, limitation of the *> physical connection between host and network etc. The proxy can *> communicate the relevant information to the host in the application *> specific, maybe compressed, form. This proxy discussion is important, but it does raise design issues. Shouldn't there be a separate subsection somewhere on proxies? *> *> Support for NSIS proxies affects the protocol in the following way: *> *) The protocol should accommodate signaling with the scope of a *> single NSIS peer relationship; the signaling could be propagated over *> multiple peer relationships all the way toward the destination (end- *> to-end). *> *) In the particular case where the proxy is not on the data path, *> NSIS might have to be extended to allow separated data and signaling *> paths, although this analysis is not initially in scope. *> I am not sure that it is best to treat proxies as a special case of path-decoupled signaling, which is what you seem to be doing here. The 2nd paragraph of sectionk 3.2.1, which treats proxies as a variant of path-coupled signaling, seems more correct. *> Further discussion of these issues is given in sections 3.2.1 and *> 3.3.3. *> *> As it can be seen from the usage cases presented in the NSIS *> requirements draft [2] the NSIS signaling procedures may depend on *> the part/type of the network where NSIS is used. In fact to satisfy What does "network type" mean? *> sometimes-conflicting requirements in [2], different procedures and *> possibly different kinds of the NSIS protocol can be used on >> different procedures and possibly different signaling applications >> can be used on *> different parts/types of the network. Sections 3.2 and 7.5 provide *> more details on this topic. *> *> 3.1.3 NSIS Protocol Components *> *> In order to achieve a modular solution for the NSIS requirements, it *> is proposed to structure what we refer to overall as 'the NSIS *> protocol' into 2 layers, similarly to the original proposal in [8]: *> *) a 'signaling transport' layer, responsible for moving signaling *> messages around, which should be independent of any particular *> signaling application; and *> *) a 'signaling application' layer, which contains functionality *> such as message formats and sequences, specific to a particular *> signaling application. *> *> For the purpose of this document, we use the term 'NSIS Transport *> Layer Protocol' (NTLP) to refer to the component that will be used in *> the transport layer; it may or may not be based on the use of *> existing transport protocols. We also use the term 'NSIS Signaling *> Layer Protocol' (NSLP) to refer generically to any protocol component *> within the signaling application layer; in the end, there will be *> several NSLPs. These relationships are illustrated in Figure 2. *> *> *> *> ^ +-----------------+ *> | | NSIS Signaling | *> | | Layer Protocol | *> NSIS | +----------------| for middleboxes | *> Signaling | | NSIS Signaling | +-----------------+ *> Layer | | Layer Protocol +--------| NSIS Signaling | *> | | for QoS | | Layer Protocol | *> | | | | for something | *> | +-----------------+ | else | *> V +-----------------+ *> ============================================= *> ^ +--------------------------------+ *> | | NSIS Transport Layer Protocol | *> NSIS | | .................... | *> Transport | | .Standard transport. | *> Layer | | . protocol (maybe) . | *> | | .................... | *> V +--------------------------------+ *> *> Figure 2: NSIS Protocol Components *> If you (really) want to take a layerist view, then the lower layer should look like: ============================================= ^ +--------------------------------+ | | NSIS Transport Layer Protocol | | | | NSIS | |................................| Transport | | Standard transport | Layer | | protocol (maybe) | V +--------------------------------+ *> The precise boundary between these layers is not defined at this *> stage; see section 3.3.5 for some initial discussion of this point. *> *> 3.2 Options for Modes of NSIS Operation *> *> This section discusses several possible modes of NSIS operation. Each *> mode of NSIS operation is briefly introduced and where needed *> analyzed and compared with the alternatives. It is not assumed that *> NSIS will support all the mode variants described in these *> subsections; after the tradeoffs described here have been evaluated, *> some might be excluded from further consideration. *> *> 3.2.1 Path-Coupled and Path-Decoupled Signaling (I basically liked the discussion of this section) *> *> We can consider two basic paradigms for resource reservation *> signaling, which we refer to as "path-coupled" and "path-decoupled". *> *> In the path-coupled case, signaling messages are routed only through *> nodes (NEs) that are in the data path. They do not have to reach all *> the nodes on the data path (for example, there could be proxies *> distinct from the sender and receiver as described in section 3.1.2, *> or intermediate signaling-unaware nodes); and between adjacent NEs, *> the route taken by signaling and data might diverge. The path-coupled *> case can be supported by various addressing styles, with messages *> either explicitly addressed to the neighbor on-path NE, or routed *> identically to the data packets and intercepted. These cases are *> considered in section 3.3.4. In the second case, some network *> configurations may split the signaling and data paths (see section *> 5.2); this is considered an error case for path-coupled signaling. *> *> In the path-decoupled case, signaling messages are routed to nodes *> (NEs) which are not assumed to be on the data path, but which are *> (presumably) aware of it. Signaling messages will always be directly *> addressed to the neighbor NE, and the NI/NR may have no relation at *> all with the ultimate data sender or receiver. *> *> There are potentially significant differences in the way that the two *> signaling paradigms should be analyzed, for example in terms of *> scaling behavior, failure recovery, security properties, mechanism *> for NSIS peer determination, and so on. These differences might or *> might not cause changes in the way that the NSIS protocol operates. *> *> The initial goal of NSIS and this framework is to concentrate mainly *> on the path-coupled case. *> *> 3.2.2 Inter-domain and Intra-domain Signaling *> I don't like this section very much. It says too much and too little. Maybe it needs to be merged with section 7.5? Maybe it needs to be grounded in a summary of RFC 2998? *> Inter-domain NSIS signaling is where the NSIS signaling messages are *> originated in one NSIS domain and are terminated in another NSIS *> domain. *> *> In the path-coupled case, inter-domain NSIS signaling can be used to *> signal NSIS information to the edge nodes of one or more NSIS *> domains. *> *> In the path-decoupled case, inter-domain NSIS signaling can be used *> to signal NSIS information to entities that are not on the data path *> (i.e., "out-of-band" NFs), and additionally to signal from off-path *> entities to on-path edge nodes . I think the paragraph above is confused. Perhaps you are introducing "path-unrelated" signaling, which I claim is different from path-decoupled signaling. (See my overview message). *> *> NSIS inter-domain signaling has to fulfill several requirements, such *> as: *> *) Basic functionality, such as scalable, simple and fast signaling. ' Boooo! "Scalable, simple, and fast" is devoid of content, and even if it did have content, it would not hold just for inter-domain signaling. *> Because different networks have different resource management *> characteristics, such as cost of bandwidth and performance, this *> basic functionality may differ from one NSIS domain to another. *> *) All other requirements specified in [2]. (Gratuitous.) *> *> Intra-domain NSIS signaling is where the NSIS signaling messages are *> originated, processed and terminated within the same NSIS domain. *> Note that these messages could be handled within a local instance of *> NSIS signaling; another possibility could be to piggyback them on *> inter-domain NSIS messages. *> *> *> *> Hancock et al. Expires - May 2003 [Page 11] *> Next Steps in Signaling: Framework November 2002 *> *> Intra-domain signaling can be used to signal NSIS information to the *> edge nodes (i.e., routers located at the border of the NSIS domain) *> and to the interior nodes (i.e., routers located within the NSIS *> domain that are not edge nodes). *> *> The NSIS intra-domain signaling approach has to fulfill fewer *> requirements than inter-domain signaling. These are: *> *) Basic functionality, such as scalable, simple and fast signaling. Booo again. *> Due to the fact that different networks have different resource *> management characteristics, this basic functionality may differ from *> one NSIS domain to another. *> *) Provides the necessary functionality to interact between inter- *> domain signaling and intra-domain signaling. *> *> 3.2.3 End-to-End, Edge-to-Edge, and End-to-Edge *> *> End-to-end: When used end-to-end, the NSIS protocol is initiated by *> an end host and is terminated by another end host. In this context, *> NSIS can be applied as needed within all of the NSIS domains between *> the end hosts. In the end-to-end path, NSIS may be used both for *> intra-domain NSIS signaling, as well as for inter-domain signaling. *> *> Edge-to-edge: In this scenario the NSIS protocol is initiated by an *> edge node of a NSIS domain and is terminated by another edge node of *> the same (or possibly different) NSIS domain. NSIS can be applied *> either within one single NSIS domain, which is denoted as edge-to- *> edge in a single domain, or within a concatenated number of NSIS *> domains, which is denoted as edge-to-edge in a multi-domain. When an *> appropriate security trust relation exists between two or more *> concatenated NSIS domains, these concatenated NSIS domains are *> considered, in terms of NSIS, to be a single, larger NSIS domain. *> *> End-to-edge: In this scenario the NSIS protocol is either initiated *> by an end host and is terminated by an edge node or is initiated by *> an edge node and is terminated by an end host. In the path-coupled *> case, the edge node may be a proxy that is located on a boundary node *> of a NSIS domain. In the path-decoupled case, the edge node may be a *> proxy that is located on an off-path node that controls, or is *> associated with, a NSIS domain. *> *> 3.2.4 Global and Local Operation *> *> It is likely that the appropriate way to describe the resources NSIS *> is signaling for will vary from one part of the network to another. *> In particular, resource descriptions that are valid for inter-domain *> links will probably be different from those useful for intra-domain #### may be *> operation (and the latter will differ from one NSIS domain to #### may *> another). *> *> One way to describe this issue is to consider the resource *> description objects carried by NSIS (typically within the signaling *> application layer) as divided in globally-understood objects ("global *> objects") and locally-understood objects ("local objects"). The local The logical necessity of this distinction is unclear. There may be a need for 'scope' of resource description objects, but it isn't clear that 1 bit (local/global) is fundamental or sufficient. *> objects are only applicable for intra-domain signaling, while the *> global objects are mainly used in inter-domain signaling. Note that *> such local objects are still part of the NSIS protocol, unlike opaque ?? Huh?? *> data which would be invisible to the protocol; local objects can be *> inserted, used and removed by one single domain. *> *> The purpose of this division is to provide additional flexibility in *> defining the objects carried by the NSIS protocol such that only *> those objects that are applicable in a particular setting are used. *> An example approach for reflecting the distinction in the signaling *> is that local objects could be put into separate local messages that *> are initiated and terminated within one single NSIS domain and/or *> they could be "stacked" within the NSIS messages that are used for *> inter-domain signaling. These possibilities will be considered *> further during the protocol design activity. *> *> 3.2.5 Multicast versus Unicast *> *> Multicast support, compared to unicast support, would introduce a *> level of complexity into the NSIS protocol mainly related to: *> *) complex state maintenance to support dynamic membership changes *> in the multicast groups, such as reservation state merging and *> maintenance. *> *) a state per flow has to be maintained that is used during *> backward routing. *> *> 3.2.6 Sender versus Receiver Initiated Signaling *> *> A sender-initiated approach is when the sender of the data flow *> initiates and maintains the resource reservation used for that flow. *> In a receiver-initiated approach the receiver of the data flow *> initiates and maintains the resource reservation used for the data *> flow. *> This is a slippery dichotomy. You have slipped into saying "reservation", which is QoS-specific. Does the distinction hold for other signaling applications? *> In the path-coupled case, and in the absence of NSIS proxies, the *> following relationships apply: *> *) in the sender initiated case, the sender of the data is the NSIS *> Initiator, while the receiver of the data is the NSIS Responder; *> *) in the receiver initiated case, the receiver of the data is the *> NSIS Initiator, while the sender of the data is the NSIS Responder. You have fallen into the Pit of Confusion here! The last statement is simply not true, as the RSVP example shows. Each of sender and receiver is both NI and NR, in the RSVP case. *> In the path-decoupled case, the mapping is not necessarily clear cut *> (for example, if the NI and NR are not located at the end systems *> themselves). *> *> The main differences between the sender-initiated and receiver- *> initiated approaches are the following: *> *) Compared with the receiver-initiated approach, a sender using a *> sender-initiated approach can be informed faster when the reservation *> request is rejected. In other words, when using a sender-initiated *> approach, the reservation request response time can be shorter in the *> case of an unsuccessful reservation than with a receiver-initiated *> approach. Yes, and a receiver using the receiver-initiated approach can be informed faster. What is your point? *> *) In a receiver-initiated approach, the signaling messages *> traveling from the receiver to the sender must be backward routed *> such that they follow exactly the same path as was followed by the *> signaling messages belonging to the same flow traveling from the *> sender to the receiver. This implies that a backward routing state *> per flow must be maintained. When using a sender-initiated approach, *> provided acknowledgements and notifications can be securely delivered *> to the sending node, backward routing is not necessary, and nodes do *> not have to maintain backward routing states. *> *) In a sender-initiated approach, a mobile node can initiate a *> reservation for its outgoing flows as soon as it has moved to another *> roaming subnetwork. In a receiver-initiated approach, a mobile node *> has to inform the receiver about its handover procedure, thus *> allowing the receiver to initiate a reservation for these flows. This again seems to be half of a dual argument, since mobile nodes both send and receive. *> *) Where the signaling is looking for the last (nearest to receiver) *> NE on the data path, receiver oriented signaling is most efficient; *> sender orientation would be possible, but take more messages. The preceding discussion was one-sided. It should mention the overwhelming scaling advantages of receiver orentation for multicast reservations. *> *> 3.2.7 Uni-Directional and Bi-Directional Reservations *> How about: "Reservations" -> "Resource Requests" *> It is possible that a resource will only be required for one *> direction of traffic, for example for a media stream with no feedback *> channel. Reservations for both directions of traffic may be required *> for other applications, for example a voice call. Therefore, the NSIS *> signaling protocol must allow for both uni- and bi-directional *> resource reservations. I would claim that the sentence above is tautologous; a signaling protocol cannot help itself from supporting bi-directional reservations. You just use the protocol in both directions, as the following sentence says. *> The most basic method for bi-directional reservations is based on *> combining two uni-directional reservations. This allows that the *> signaling messages for one direction of the bi-directional *> reservation are able to follow a different path from messages *> traveling in the opposite direction, which is necessary for path- *> coupled signaling in the presence of asymmetric routing. (Other more *> integrated approaches may be possible in constrained network *> topologies where parts of the route are symmetric.) The bi- *> directional reservations can, for example, be used to make the NSIS *> signaling procedure required after a handover procedure more *> efficient. *> How about: A resource will only be required for one direction of traffic, for example QoS for a media stream with no feedback channel. On the other hand, some applications will have bi-directional resource requirements; an example is QoS for a voice call. Bi-directional resource requests can simply use a separate instance of the same signaling mechanism in each direction. Note that the paths in the two directions may differ due to assymmetric routing. In constrained topologies where parts of the route are symmetric, it may be possible to use a more unified approach to bi-directional signaling, e.g., carrying the two signaling directions in common messages. This optimization might be used to make mobile QoS signaling more efficient. *> *> *> 3.3 Basic Assumptions and Conceptual Issues *> *> 3.3.1 Basic Assumptions *> *> The following assumptions have been made during prior NSIS *> requirements work and initial framework discussions. They are *> summarized here for completeness. The subsequent subsections describe *> more generic conceptual assumptions and issues. Note that a complete *> overview of current open issues is contained in section 8. *> *> *) The solution developed by NSIS must be sufficiently flexible and *> modular that it can be efficiently deployed and used with *> functionality appropriate to the part/type of the network. (Sections *> 3.2.2 and 3.2.3.) *> *> *) The protocol developed by the NSIS working group will be path- *> coupled. Considerations related to a potential path-decoupled *> solution are part of this framework, because they are also needed in *> order to co-exist with existing solutions; however, the NSIS working *> group currently has no plans to develop path-decoupled signaling *> protocol. (Section 3.2.1.) *> *> *) End-to-end message routing will be achieved by each NE *> determining the next appropriate NSIS peer, based on the flow in *> question and information within the NTLP layer, not requiring any *> node or the upper layers to acquire end-to-end topology information. This seems like a statement about detailed design that may in fact be wrong for some signaling applications. *> (Section 3.2.4.) Sectionk 3.2.4?? I don't see the relevance. *> *> *) Multicast support introduces a level of complexity into the NSIS *> protocol that is not needed in support of unicast applications. *> Therefore, a working assumption is be that the NSIS protocol should *> be optimized for unicast. (Section 3.2.5.) *> *> *) The NSIS protocol can be used for setup of both uni-directional *> and bi-directional reservations. (Section 3.2.7.) *> *> 3.3.2 NI, NF, NR functionality *> *> The basic functions that can be fulfilled by an NSIS entity are *> request, accept, notify, modify and release of a reservation. At this A "reservation"? Sounds like an assumption of QoS signaling. There was an extended debate in the RSVP WG about whether or not an Accept is required, and in the end only a very weak form of it was included. Need definitions of these terms (which are redundantly supplied in section 4.2; these should be combined.) *> point, it is not clear which responsibilities can be assumed by each *> of the NSIS entities. More in particular, it is not clear whether: *> *) an NF can request, modify or release a reservation. If it cannot, *> it needs to notify the NI in order to perform these functions. #### it would need to ... *> *) an NR can modify and release a reservation. Even if the NR can *> reject or accept the reservation with modification, it might still be *> required to notify the NI to signal the release or modification. *> *> *> 3.3.3 NI, NF, NR relationship *> *> An important open issue is related to the way in which NSIS entities *> maintain relations between each other. These relations could be *> purely local, where an NSIS entity only maintains relations with its *> direct neighbors (peers). In that case, messages will be sent to and *> accepted from these neighbors only. Alternatively, the relations *> between NSIS entities could have a more global scope. *> I like this paragraph, because you slipped into using the terms I favor, "neighbors" ;-). More seriously, the neighbor/peer distinction surfaces here. How about: NSIS entities that communicate with each other are peers. Peering of entities might be limited to neighbor nodes, so that entities can only communicate hop/hop along the path. Alternatively, the framework might allow remote peering, i.e., peering with nodes that are not neighbors. *> The type of NSIS peering relations may have an impact on the *> complexity involved with protocol security. In case of inter-domain *> signaling, the security relations are likely to be built between *> neighboring NSIS entities only for scalability reasons. In that case, *> each NSIS entity will establish and maintain a security relation with *> each of its peers and accept only messages from these peers. *> *> Conversely, there may exist larger domains of NSIS entities that have *> a trust relationship (trusted domains). This may be the case for *> intra-domain signaling. In this case, an NE may accept messages from *> all other NSIS entities in the domain. Both alternatives need not be *> mutually exclusive. It is conceivable that different instances of the *> NSIS protocol (or different NSIS protocols) use the NSIS security *> model to a larger or lesser extent, provided that overall security is *> not impacted. An analysis of NSIS threats is available from [5]. *> *> The NSIS peering relations may also have an impact on the required *> amount of state at each NSIS entity. When direct interaction with *> remote NSIS peers is not allowed, it may be required to keep track of *> the path that an NSIS message has followed through the network. This *> can be achieved by keeping per-flow state at the NSIS entities or by *> maintaining a record route object in the NSIS messages. *> *> An initial working assumption is that the NTLP will operate *> 'locally', that is, just over the scope of a single peer *> relationship. End-to-end operation is built up by simply *> concatenating these relationships. Any non-local operation (if any) *> will take place only in particular NSLPs. *> *> 3.3.4 NSIS Addressing *> *> The are potentially two ways to establish a signaling connection by "connection"? Overloaded word... *> means of the NSIS protocol. On the one hand, the NSIS message could *> be addressed to a neighboring NSIS entity (NE) that is known to be *> closer to the destination NE. On the other hand, the NSIS message *> could be addressed to the destination directly, and intercepted by an *> intervening NE. We denote the latter approach as end-to-end *> addressing and the former as peer-peer addressing. *> *> With peer-peer addressing, an NE will determine the address of the *> next NE based on the payload of the NSIS message (and potentially *> also on the previous NE). This requires the address of the *> destination NE to be derivable from information present in the *> payload. This can be achieved through the availability of a local *> routing table or through participation in the routing protocol. Peer- *> peer addressing inherently supports tunneling of NSIS signaling *> messages between NEs, and is equally applicable to the path-coupled *> and path-decoupled cases. *> *> In case of end-to-end addressing, the NSIS message will be sent with *> the address of the NR, which then necessarily needs to be on the data *> path. This requires (some of) the data-path entities to be upgraded *> (NSIS-aware) in order to be able to intercept the NSIS messages. The *> routing of the NSIS signaling should follow exactly the same path as *> the data flow for which the reservation is requested. *> *> 3.3.5 NSIS Layer Boundaries *> *> The detailed boundary between the NTLP and NSLPs is an area for *> (considerable) further analysis. In particular, it is not clear how *> the key issues described earlier (such as sender/receiver *> orientation) are allocated to the different layers. However, some *> initial assumptions have been made about the functionality in *> different layers. *> *> *) It is assumed that some flow description information is part of #### flow identification is part of *> the NTLP (see section 4.3.1 and 4.5.1). This might be needed by *> signaling application unaware entities located at address boundaries. *> It is not clear to which level of complexity the flow description *> needs to be available at this level. Note that my 2level model does NOT make this assumption. CSTP (your NTLP) is not aware of the flow indentification for a signaling packet; that is up to the particular ULSP. I would suggest that my modularity is better, since the choice of flow indentification is probably specific to different classes of signaling applications. Making the CSTP aware of the FId will require that you identify the most general possible FId early on, which seems like a bad idea. (On the other hand, you may be able to show that my design in fact has some serious drawback, so that FId info is essential in the lower level.) *> *) It is not assumed that the operation of an NSLP is totally *> independent of the NTLP; for example, the appropriate interpretation *> of an NSLP message might depend on the local status of the NTLP. *> I disagree with this. How about: *) It is highly desirable to be able to create NSLP signaling applications that are independent of the internal operation of the NSLP. This modularity will allow independent evolution of the two protocol layers. *> 3.3.6 NSIS Acknowledgement and Notification Semantics *> *> The semantics of the acknowledgement and notification messages are of *> particular importance. An NE sending a message can assume *> responsibility for the entire downstream chain of NEs, indicating for *> instance the availability of reserved resources for the entire *> downstream path. Alternatively, the message could have a more local *> meaning, indicating for instance that a certain failure or *> degradation occurred at a particular NSIS entity. *> *> *> *> *> *> 4. Protocol Components *> *> 4.1 Lower Layer Interfaces *> *> Within a signaling entity, NSIS interacts with the 'lower layers' of Within an NE? Or within a node that supports an NE? (Terminolgy alarm) *> the protocol stack for two nearly independent purposes: sending and *> receiving signaling messages; and configuring the operation of the *> lower layers themselves. *> *> For sending and receiving messages, this framework places the lower *> boundary of the NTLP at the IP layer. (It is possible that NSIS could *> use a standard transport protocol above the IP layer to provide some *> of its functionality; this is discussed in section 4.3.1.) The *> interface with the lower layers is therefore very simple: *> *) The NTLP sends raw IP packets *> *) The NTLP receives raw IP packets. In the case of peer-peer *> addressing, they have been addressed directly to it. In the case of *> end-to-end addressing, this will be by intercepting packets that have *> been marked in some special way (by special protocol number or by *> some option interpreted within the IP layer, such as the Router Alert *> option [6] and [7].) *> *> For correct message routing, the NTLP needs to have some information *> about the link and IP layer configuration of the local networking *> stack. For example, it needs to know: You probably need route change notification upcalls for local repair, and you may need route pinning. *> *) [in general] how to select the outgoing interface for a signaling *> message, in case this needs to match the interface that will be used *> by the corresponding flow. This might be as simple as just allowing *> the IP layer to handle the message using its own routing table. *> *) [in the case of IPv6] what address scopes are associated with the *> interfaces that messages are sent and received on (to interpret *> scoped addresses in flow identification, if these are to be allowed). *> *> The way in which the lower layers are actually configured to handle *> the flow depends on the particular NSIS signaling application; for *> example, if NSIS is being used for QoS signaling, this might involve *> configuration of traffic classification and conditioning parameters, *> for example local packet queues, type of filters, type of scheduling, *> and so on. However, none of this is directly related to the NTLP or *> indeed any NSLP; therefore, this interaction is handled indirectly *> via a resource management function, as described in section 5.1. *> *> 4.2 Upper Layer Services *> *> The combination of the NTLP and an NSLP provides a signaling service, *> appropriate for a particular signaling application. We can describe *> such a signaling service as an abstract set of capabilities, provided *> at a service interface, defined from three perspectives: *> *> *> Hancock et al. Expires - May 2003 [Page 18] *> Next Steps in Signaling: Framework November 2002 *> *> *) What basic control primitives are available at the interface; *> *) What information is exchanged within these primitives; *> *) What assumptions are made about operations carried out above the *> interface. *> *> The set of control primitives required is quite small. *> At the initiating (NI) end: *> *) Signaling application requests signaling for a new resource; *> *) Signaling application requests modification or removal of an *> existing resource. *> *) Signaling application receives progress indications (minimally, *> success or failure). *> At the responding (NR) end: *> *) Notification to signaling application that a resource has been *> set up. *> At either end: *> *) Notification to signaling application that something has changed *> about the available resource and other error conditions. *> The list above should be combined with section 3.3.2. *> This description is in terms of a 'hard state' interface, without No. How about: These control primitives are independent of the issue of whether the control information [state] must be removed with an explicit release request (hard state) or whether it will time out in the absence of refresh messages (soft state). The latter will ensure that state is removed despite possible failure of signaling applications. *> explicit refresh messages between the signaling application and NSIS, *> although this is an implementation issue. In any case, *> implementations will need to be able to detect conditions when *> instances of signaling applications fail without issuing explicit *> resource removal requests. *> *> The information in the control primitives consists essentially of two *> parts. The first is the definition of the data flow for which the *> resource is being signaled. The format (e.g. socket id or packet *> fields or whatever) is an implementation issue; it has to be *> interpreted into a 'wire format' (as in section 4.5). Since NSIS *> could support both sender and receiver initiation, the flow *> definition must also state whether it is incoming or outgoing over a *> particular interface (this can be inferred when the initiator is *> colocated with the flow endpoint). The second part of the information *> exchanged is the service definition (e.g. QoS description in the case *> of a QoS request). This will be opaque at least to the NTLP, which *> only knows the specific NSLP being used. *> *> We have a basic design goal not to duplicate functionality that is *> already present in (or most naturally part of) existing signaling *> protocols which could be used by the upper layers. Therefore NSIS *> (implicitly) assumes that certain procedures are carried out *> 'externally'. The main aspects of this are: *> *) Negotiation of service configuration (e.g. discovering what *> services are available to be requested); *> *) Agreement to use NSIS for signaling, and coordination of which *> end will be the initiator. This is good. *> *> *> Hancock et al. Expires - May 2003 [Page 19] *> Next Steps in Signaling: Framework November 2002 *> *> *> In addition, as well as NSIS (presumably the NTLP) providing a *> 'native' capability to determine the peer to carry out signaling *> with, it is possible that this information could be provided from *> some external source (which might be helpful in some access *> scenarios, or in the path-decoupled case). See also the security *> discussion in section 6. *> *> Actually providing these functions might require enhancements to *> these other protocols. These are still to be identified. *> *> 4.3 Protocol Structure *> *> 4.3.1 Internal Layering *> *> We can model NSIS in two layers, as shown in Figure 3. This is *> initially just a way of grouping associated functionality, and does *> not mean that all these layers could necessarily operate or even be *> implemented independently. I'm not sure I agree with the last sentence. *> *> .................................. *> . Signaling Application . *> . (section 4.2) . *> . . *> +--------------------------------+ *> | NSIS Signaling Layer Protocol | *> | (for some specific signaling | *> | application) | *> | | *> +--------------------------------+ *> | NSIS Transport Layer Protocol | *> | .................... | *> | .Standard transport. | *> | . protocol (maybe) . | *> | .................... | *> +--------------------------------+ *> . Interface to IP layer . *> . (section 4.1) . *> . . *> .................................. *> *> Figure 3: NSIS Layer Structure This diagram seems redundant with Figure 2. See also my comment there. *> *> The lower layer interface (to IP) has been described in section 4.1. *> The support of the signaling application is as described in section *> 4.2. The degree of independence between the NTLP and NSLP is unclear *> and might depend on the particular signaling application. To make the *> NTLP independent of the signaling application, we must allow that *> NSLPs could be explicitly dependent on the layer below. This is ?? Huh?? I don't understand this. *> similar to the ALSP/CSTP coupling described in [8]. *> *> The distinction between the NTLP and any 'Standard Transport *> Protocol' is not functionally clear cut, but one of convenience. In *> outline: *> *) The 'standard' protocol could provide (at most) functionality *> which might be available from existing protocols, such as SCTP [9] or *> IPSec [10]. An extreme case could be the binding update messages of *> mobility signaling (section 5.3.4). *> *) The NTLP provides (at least) functionality which is somehow *> specific to path-coupled signaling. *> *> Functionality reasonable to re-use from existing protocols might *> include reliability and re-ordering protection, dead peer detection *> (keepalive), multihoming support, payload multiplexing (BTW, strictly, existing transport protocols (TCP, UDP) don't provide keep-alives. The NTLP can program keep-alives, however.) *> (piggybacking), and security services, such as establishment of *> security contexts and carrying out key exchange. *> *> Functionality which would probably have to be in the NTLP would *> include flow and reservation identification, some error handling, >> ................................... (See my earlier comment about CSTP) *> demultiplexing between different NSLPs, as well as possibly the basic *> NSIS messages. More details on the messages are in section 4.3.2 and *> the identifier aspects in section 4.5. *> *> The choice of using functionality from an existing protocol or re- *> specifying it as part of the NTLP is for further analysis. It *> probably depends on the function in question, and in the end might be *> left flexible to allow optimization to local circumstances. (For *> example, Diameter allows the use of IPSec for security services, but *> also includes its own CMS application as an alternative.) Whichever *> approach is taken, the combination of NTLP and supporting transport *> protocol must provide a uniform protocol capability to the NSLPs *> which support the actual signaling applications. *> *> 4.3.2 Protocol Messages *> *> The NSIS protocols will include a set of messages to carry out *> particular operations along the signaling path. Initial work for RSVP *> concentrated on the particular case of QoS signaling, although the *> implication of the analysis in [8] is that this message set *> generalizes to a wide variety of signaling applications and so we use *> it as a starting point. (A very similar set of messages was generated *> in [11].) However, in principle, the necessary basic messages could *> depend on the signaling application that NSIS is being used for, *> which means that we are not specific here about whether these *> messages are visible within the NTLP or only NSLP. *> *> Note that the 'direction' column in the table below only indicates *> the 'orientation' of the message. The messages can be originated and *> absorbed at NF nodes as well as the NI or NR; an example might be NFs *> at the edge of a domain exchanging NSIS messages to set up resources *> for a flow across a it. I question that example; perhaps it would be more consistent with the model to consider that the NFs at the edge are then acting as NIs. *> *> Note the working assumption that responder as well as the initiator *> can release a reservation (comparable to rejecting it in the first *> place). It is left open if the responder can modify a reservation, *> during or after setup. This seems mainly a matter of assumptions *> about authorization, and the possibilities might depend on resource *> type specifics. *> *> +-------+---------+---------------------------------------------+ *> | Name |Direction| Semantics | *> +-------+---------+---------------------------------------------+ *> |Request| I-->R | Create a new reservation for a flow | *> +-------+---------+---------------------------------------------+ *> |Modify | I-->R | Modify an existing reservation | *> | |(&R-->I?)| | *> +-------+---------+---------------------------------------------+ *> |Release| I-->R & | Delete (tear down) an existing reservation | *> | | R-->I | | *> +-------+---------+---------------------------------------------+ *> |Accept/| R-->I | Confirm (possibly modified?) or reject a | *> | Reject| | reservation request | *> +-------+---------+---------------------------------------------+ *> |Notify | I-->R & | Report an event detected within the | *> | | R-->I | network (e.g. congestion condition or end | *> | | | of condition) | I worry about a naive introduction of congestion mechanism here. How will it interact with Internet congestion control? Internet congestion is a large and deep topic. *> +-------+---------+---------------------------------------------+ *> |Refresh| I-->R | State management (see section 4.4) | *> +-------+---------+---------------------------------------------+ *> *> The table also explicitly includes a refresh message. This does *> nothing to a reservation except extend its lifetime, and is one *> possible state management mechanism for NSIS. This is considered in *> more detail in section 4.4. *> *> 4.4 State Management *> *> The prime purpose of NSIS is to manage state information along the *> path taken by a data flow. There two critical issues to be considered *> in building a robust protocol to handle this problem: *> *) The protocol must be scalable. It should minimize the state *> storage demands that it makes on intermediate nodes; in particular, *> storage of state per 'micro' flow is likely to be impossible except *> at the very edge of the network. How about: For example, storage of resource state for every micro-flow may be infeasible in core networks but feasible at the network edges. *> *) The protocol must be robust against failure and other conditions, *> which imply that the stored state has to be moved or removed. *> *> The total amount of state that has to be stored depends both on NSIS *> and on the specific signaling application in use. The signaling *> application might require per flow or lower granularity state; #### per micro-flow or ... *> examples of each for the case of QoS would be IntServ or RMD (per *> 'class' state) respectively. The NSIS protocol should not overburden *> an application that was otherwise lightweight in state requirement. WHAT does that last sentence mean?? (Suggest delete it.) *> However, depending on design details, it might require storage of *> per-flow state including reverse path peer addressing, simply for *> sending NSIS messages themselves. *> *> There are several robustness problems, which roughly align with the *> 'layers' of the NSIS protocols of Figure 3, that can be handled by *> the soft state principle. (Independence of these layers therefore *> implies the danger of duplication of functionality.) This relies on What does the sentence in parentheses mean? *> periodic refresh of the state information with the current context, *> relying on invalid state being timed out. Soft state can be used *> either as the primary mechanism to handle the problem, or sometimes *> as a backup to some other approach. *> You can be more explicit than "some other approach". *> *) At the lowest level, soft state can be used to detect dead NSIS *> peers - loss of several periodic messages implies termination of the *> signaling. (The same inference can be made e.g. if failure is *> detected at the link layer.) The assumption is then that the *> corresponding reservation should be automatically deleted, and the *> deletion propagated along the remainder of the path. *> *> *) At the next level, in the event of a routing change (for example *> caused by network changes or end host mobility), reservation state *> should be removed from the old path and added to the new one. This *> will be handled automatically by periodic messaging, provided that *> the entities on the new path accept a Refresh message to install a *> new reservation. (A partial alternative is to have a routing-aware *> NSIS implementation, if the route change takes place at an NSIS-aware *> node.) How about: To provide immediate response to a routing change, it is desirable to have the signaling protocol notified of routing changes so it can do local repair. *> *> *) At the highest level, a particular signaling application might *> have timing limits associated with a particular reservation (e.g. *> credit limited network access). Periodic re-authorized requests can *> be used as part of the time control. *> *> All of these can be handled with a single soft state mechanism, *> although it may be hard to choose a single refresh interval and *> message loss threshold appropriate for all of them. Even where *> alternative approaches are possible, for example using knowledge of *> the fact that a routing change has occurred to trigger an explicit *> release message, it seems that a soft state mechanism is always *> necessary as a backup. *> Even such a soft-state booster as myself would not claim "necessary"; how about "desirable"? *> 4.5 Identity Elements *> *> NSIS will carry certain identifiers within the NTLP. The most *> significant identifier needs seem to be the following. *> *> 4.5.1 Flow Identification *> *> The flow identification is a method of identifying a flow in a unique *> way. All packets and/or messages that are associated with the same *> flow will be identified by the same flow identifier. In principle, it #### flow identification. For example, it *> could be a combination of the following information (note that this *> is not an exclusive list of information that could be used for flow *> identification): *> *) source IP address; *> *) destination IP address; *> *) protocol identifier and higher layer (port) addressing; *> *) flow label (typical for IPv6); *> *) SPI field for IPSec encapsulated traffic; *> *) DSCP/TOS field *> *> We've assumed here that the flow identification is not hidden within *> the NSLP, but is explicitly part of the NTLP. The justification for *> this is that it might be valuable to be able to do NSIS processing *> even at a node which was unaware of the specific signaling *> application; this would be a case of an NSIS forwarder with no *> interface to any resource management function. An example scenario *> would be NSIS messages passing through an addressing boundary where *> the flow identification had to be re-written. *> This is an interesting example, but I still think that such rewriting would want to be done at the ULSP level. You have to make some strong assumptions here (which are not discussed anywhere in your document): that the SAPU is encoded in such a way that an NE that is unaware of its detailed contents can still determine what fields contain addresses that need to be translated. Or else, you HAVE to have an instance of a particular signaling application to do the rewriting in any node. *> The very flexibility possible in flow classification is a possible *> source of difficulties: when wildcards or ranges are included, it is *> probably unreasonable to assume a standard classification capability *> in routers; on the other hand, negotiating this capability would be a *> significant protocol complexity. *> *> 4.5.2 Reservation Identification *> *> There are several circumstances where it is important to be able to *> refer to a reservation independently of whatever other information is #### its flow identification.XXXXX *> associated with it. The prime example is a mobility-induced address #### XXXXXXXXXXXXXXXXXXX *> change (handover) which required the flow identifier associated with #### flow identification *> a reservation to be rewritten without installing a totally new *> reservation (see section 5.3.1 for some security and scoping *> implications of this use). The same capability could also be used to *> simplify refresh or release messages in some circumstances, and might *> be useful within the protocol to resolve reservation collisions *> (where both sender and receiver initiate for the same flow). I have yet to be convinced that it is actually "important". The last reason seems weak; a competant protocol design would take account of such collision if it is a possibility, and using the flow identification. *> *> A reservation identifier performs these roles. It is open how the *> reservation identifier space should be defined and managed, and what *> the scope of the identifier should be (only peer-peer, or end-end, *> when interpreted in conjunction with some of the addressing *> information). Some of the necessary identifier functions, especially *> to do with local operation of NSIS, may also be provided by lower *> layer signaling transport protocols. *> *> 4.5.3 NSLP Identification *> *> Since the NTLP can be used to support several NSLPs, there is a need *> to identify which one a particular NSIS message is being used for: *> *) processing incoming messages at a responder - the NTLP should be *> able to demultiplex these towards the appropriate signaling *> application; *> *) processing general NSIS messages at an NSIS aware intermediate *> node - if the node does not handle the specific signaling *> application, it should be able to make a forwarding decision without *> having to parse the upper layer information. *> *> Signaling application identifiers would probably require an IANA *> registry. *> *> 5. NSIS Protocol Interactions *> *> So far as possible, the NSIS protocol should be usable in isolation, *> without explicitly depending on other protocols to operate. However, *> in many cases, NSIS functionality overlaps with the problem spaces of *> other protocols. In order to determine the boundaries which minimize *> any explicit interdependencies, these protocol interactions must be *> analyzed. *> *> This is different from considering the use of NSIS protocols to *> support a particular signaling application, or example configurations *> in which NSIS might be deployed. These subjects are discussed in *> section 7. *> *> 5.1 Resource Management Interactions *> (See my overview message about this section). ... *> *> 5.2 IP Routing Interactions *> *> Several situations may occur when routing diverges from standard *> layer 3 routing. These are summarized in the sections below. There is a LOT more to say about routing interactions, even with "standard layer 3 routing"!! *> *> 5.2.1 Load Sharing *> *> Load sharing or load balancing is a network optimization technique *> that exploits the existence of multiple paths to the same destination *> in order to obtain benefits in terms of protection, resource *> efficiency or network stability. The significance of load sharing in *> the context of NSIS is that, if the load sharing mechanism in use *> will forward packets on any basis other than source and destination *> address, routing of NSIS messages using end-to-end addressing does *> not guarantee that the messages will follow the data path. In this *> section, we briefly survey what standard methods have been used for *> load sharing within standard routing protocols. *> *> In OSPF, load balancing can be used between equal cost paths [12] or *> unequal cost paths. An example of the latter approach is Optimized *> Multi Path (OMP). OMP discovers multiple paths, not necessarily equal *> cost paths, to any destinations in the network, but based on the load *> reported from a particular path, it determines which fraction of the *> traffic to direct to the given path. Incoming packets are subject to *> a (source, destination address) hash computation, and effective load *> sharing is accomplished by means of adjusting the hash thresholds. *> *> BGP [13][14] advertises the routes chosen by the BGP decision process *> to other BGP speakers. In the basic specification, routes with the *> same Network Layer reachability information (NLRI) as previously *> advertised routes implicitly replace the original advertisement, *> which means that multiple paths for the same prefix cannot exist. *> Recently, however, a new mechanism was defined that will allow the *> advertisement of multiple paths for the same prefix without the new *> paths implicitly replacing any previous ones [15]. The essence of the *> mechanism is that each path is identified by an arbitrary identifier *> in addition to its prefix. *> *> The distribution of traffic over the available path may be done per *> destination, per message in a round-robin fashion or with a *> predefined hashing function. The determination of the hashing image *> may take into account the source/destination IP address, QoS *> information such as the DSCP or protocol ID. When the routing *> decision is no longer based on the destination address only, however, *> there is a risk that data plane messages and control plane messages *> will not follow the same route. *> *> *> *> *> Hancock et al. Expires - May 2003 [Page 27] *> Next Steps in Signaling: Framework November 2002 *> *> 5.2.2 QoS Routing *> *> The are several proposals for the introduction of QoS awareness in *> the routing protocols. All of these essentially lead to the existence *> of multiple paths (with different QoS) towards the same destination. *> As such, they also contain an inherent risk for a divergence between *> control plane and data plane, similar to the load sharing case. *> *> For intra-domain traffic, the difference in routing may result from a *> QoS-aware traffic engineering scheme, that e.g. maps incoming traffic *> to LSPs based on multi-field classification. In BGP, several *> techniques for including QoS information in the routing decision are *> currently proposed. A first proposal is based on a newly defined *> BGP-4 attribute, the QoS_NLRI attribute [16]. The QoS_NLRI attribute *> is an optional transitive attribute that can be used to advertise a *> QoS route to a peer or to provide QoS information in along with the *> Network Layer Reachability Information (NLRI) in a single BGP update. *> A second proposal is based on controlled redistribution of AS routes *> [17]. It defines a new extended community (the redistribution *> extended community) that allows a router to influence how a specific *> route should be redistributed towards a specified set of eBGP *> speakers. The types of redistribution communities may result in a *> specific route not being announced to a specified set of eBGP *> speakers, that it should not be exported or that the route should be *> prepended n times. *> *> 5.2.3 Route pinning *> *> Route pinning refers to the independence of the path taken by certain *> data packets from reachability changes caused by routing updates from *> an Interior Gateway Protocol (OSPF, IS-IS) or an Exterior Gateway *> Protocol (BGP). This independence may for instance be caused by the *> configuration of static LSPs or by the establishment of explicitly *> routed LSPs by means of a signaling protocol (RSVP-TE or CR-LDP). If *> the NSIS signaling messages follow standard Layer 3 routing, this may *> cause a divergence between control plane and data plane. If *> reservations are made on the control plane, this may result in *> sending data along an unreserved path while maintaining a reservation *> on a path that is not used. *> *> 5.2.4 Route Changes *> *> In this section, we will explore the expected interworking between a *> signaling for resource BGP routing updates, although the same applies *> for any source of routing updates. The normal operation of the NSIS *> protocol will lead to the situation depicted in Figure 5, where the *> reserved resources match the data path. *> *> *> reserved +----+ reserved +----+ *> ------->| NF |----------->| NF | *> +----+ +----+ *> ===================================== *> data path *> *> Figure 5: Normal NSIS protocol operation *> *> A route change (triggered by a BGP routing update for instance) can *> occur while such a reservation is in place. In case of RSVP, the *> route change will be installed immediately and any data that is sent *> will be forwarded on the new path. This situation is depicted *> Figure 6. *> *> Route update *> | *> v *> reserved +----+ reserved +----+ *> ------->| NF |----------->| NF | *> +----+ +----+ *> ========== | *> || | +----+ *> || +---------->| NF | *> || +----+ *> ============================ *> data path *> *> Figure 6: Route Change *> *> Resource reservation on the new path will only be started once the *> next control message is routed along the new path. This means that *> there is a certain time interval during which resources are not *> reserved on (part of) the data path. To minimize this time interval *> several techniques could be considered. As an example, RSVP [18] has *> the concept of local repair, where the router may be triggered by a *> route change. In that case the RSVP node can start sending PATH *> messages directly after the route has been changed. Note that this *> option may not be available for NSIS if no per-flow state is kept in *> the NF. *> *> It is not guaranteed that the new path will be able to provide the *> same guarantees that were available on the old path. Therefore, in a *> more desirable scenario, the NF should wait until resources have been *> reserved on the new path before installing the route change. The *> route change procedure then consists of the following steps: *> 1. NF receives a route announcement, *> 2. Refresh messages are forwarded along the current path, *> *> *> *> Hancock et al. Expires - May 2003 [Page 29] *> Next Steps in Signaling: Framework November 2002 *> *> 3. A copy of the refresh message is remarked as request and send *> along the new path that was announced, *> 4. When the NF has been acknowledged about the reservations on the *> new path the route will be installed and the traffic will flow along *> the new path. *> *> Another example related to route changes is denoted as severe *> congestion and is explained in [19]. This solution adapts to a route *> change, when a route change creates a congestion on the new routed *> path. *> *> 5.2.5 Router Redundancy *> *> In some environments, it is desired to provide connectivity and per *> flow or per class resource management with high-availability *> characteristics, i.e. with rapid transparent recovery even in the *> presence of route changes. This may involve interactions with the *> basic protocols which are used to manage the routing in this case, *> such as VRRP [20]. A future version of this document may consider *> interactions between NSIS and such protocols in support of high *> availability functionality. *> *> 5.3 Mobility Interactions *> *> The interactions between mobility and resource signaling protocols *> have been extensively analyzed in recent years, primarily in the *> context of RSVP and Mobile IP interaction (e.g. [21]), but also in *> the context of other types of network (e.g. [22]). This analysis work *> has shown that some difficulties in the interactions are quite deep *> seated in the detailed design of these protocols; however, the *> problems and their possible solutions fall under five broad headings. *> The main issue is to limit the period after handovers during which *> the resource state has not been installed on the path, in particular *> the new part of the path. *> *> We can use this work as the starting point for considering the *> framework aspects of a new signaling protocol like NSIS, which will *> need to interwork with mobility signaling, from Mobile IP to mobility *> paradigms based on micromobility or application layer approaches. *> *> 5.3.1 Addressing and Encapsulation *> *> A mobility solution typically involves address reallocation on *> handover (unless a network supports per host routing) and may involve *> special packet formats (e.g. the routing header and Home Address *> option of MIPv6). Since NSIS may depend on end system addresses for *> forwarding signaling messages and defining flows (section 4.5.1), the *> special implications of mobility for addressing need to be *> *> *> Hancock et al. Expires - May 2003 [Page 30] *> Next Steps in Signaling: Framework November 2002 *> *> considered. Examples of possible approaches that could be used to *> solve the addressing and encapsulation problem are as follows: *> *) Use a flow identification based on low level IP addresses (e.g. *> the Care of Address) and other 'standard' fields in the IP header. *> This makes least demands on the packet classification engines within *> the network. However, it means that even on a part of the flow path *> which is unchanged, the reservation will need to be modified to *> reflect the changed flow identification (see section 5.3.3). *> *) Use a flow identification that does not change (e.g. based on *> Home Address); this is the approach assumed in [23]. This simplifies *> the problem of reservation update, at the likely cost of considerably *> complicating the flow identification requirements. *> *> In the first approach, to prevent double reservation, NSIS nodes need I wonder about the emphasis on double reservation. It is unclear to me that this is really a primary issue. I understand that these networks are typically under-provisioned (though I wonder how long that will be true as the technology continues to mature), but that can be statistically compensated for by a bit of over-booking ;-) oops, sorry, I meant optimistic reservation. It seems quite possible to me that one can get good enough service, with much simpler protocols, if you just forget about the double-reservation problem. A combination of local repair, timeouts, and judicious optimistic reservation might work most of the time. Are there simultation results on these questions? *> to be able to recognize that a reservation with the new flow *> identifier is to be correlated with an existing one. The reservation *> identifier (section 4.5.2) was introduced for exactly this purpose. *> Note that this would require the reservation identifier to have *> (secure) end to end significance. (An additional optimization here *> would be use a local mobility management scheme to localize the *> visibility of the address change.) *> *> The feasibility and performance of this first approach needs to be *> assessed, including a detailed analysis of the signaling scenarios *> after a handover. However, given the high impact of requiring more *> sophisticated packet classifiers, initially it still seems more *> plausible than the second approach. This implies that the NSIS *> initiator should define flows in terms of real (care of) addresses *> rather than virtual (home) addresses. Thus, it would have detailed *> access to lower layer interface configuration (cf. section 4.1), *> rather than operating as a pure application level daemon as is *> commonplace with current RSVP implementations. *> *> 5.3.2 Localized Path Repair *> *> In any mobility approach, a handover will cause at least some changes *> in the path of upstream and downstream packets. NSIS needs to install *> new state on the new path, and remove it on the old. Provided that *> some NSIS node on the joined path - the crossover router - can *> recognize this situation (which again depends on reservation *> identification), state installation and teardown can be done locally *> between it and the mobile node. (This may have implications for which *> entities are allowed to generate which message types, see section *> 4.3.2). It seems that the basic NSIS framework already contains the *> fundamental components necessary for this. *> *> A critical point here is the signaling that is used to discover the *> crossover router. This is a generalization of the problem of finding *> next-NSIS-hop nodes: it requires extending the new path over several *> hops until it intersects the old one. This is easy for uplink traffic *> (where the mobile is the sender), but much harder for downlink *> traffic without signaling via the correspondent. There is no reason *> for the crossover routers for uplink and downlink flows to be the *> same, even for the same correspondent. The problem is discussed *> further in [24]. *> *> 5.3.3 Reservation Update on the Unchanged Path *> *> On the path between the crossover router(s) and the correspondent, it *> is necessary to avoid, if possible, double reservations, but rather Ditto. *> to update the reservation state to reflect new flow identification *> (if this is needed, which is the default assumption of section *> 5.3.1). Examples of approaches that could be used to solve this *> problem are the following: *> *) Use a reservation state definition that does not change even if *> the flow definition changes (see Section 4.5.2). In this case this *> problem is solved. *> *) Use signaling all the way to the correspondent node (receiver end *> host), accepting the additional latency that this might impose. *> *) Use an NSIS-capable crossover router that manages this *> reservation update autonomously (more efficiently than the end *> nodes), with similar considerations to the local path repair case. *> *> 5.3.4 Interaction with Mobility Signaling *> *> In existing work on mobility protocol and resource signaling protocol *> interactions, several framework proposals describing the protocol *> interactions have been made. Usually they have taken existing *> protocols (Mobile IP and RSVP respectively) as the starting point; it *> should be noted that an NSIS protocol might operate in quite a *> different way. In this section, we provide an overview of how these *> proposals would be reflected in framework of NSIS. The mobility *> aspects are described using Mobile IP terminology, but are generally *> applicable to other network layer mobility solutions. The purpose of *> this overview is not to select or prioritise any particular approach, *> but simply to point out how they would fit into our framework and any *> major issues with them. *> *> We can consider that two signaling processes are active: mobility *> signaling (e.g. binding updates or local micromobility signals) and *> NSIS. The discussion so far considered how NSIS should operate. There *> is still a question of how the interactions between the NSIS and *> mobility signaling should be considered. *> *> The basic case of totally independent specification and *> implementation seems likely to lead to ambiguities and even *> *> *> Hancock et al. Expires - May 2003 [Page 32] *> Next Steps in Signaling: Framework November 2002 *> *> interoperability problems (see [23]). At least, the addressing and *> encapsulation issues for mobility solutions that use virtual links or *> their equivalents need to be specified in an implementation-neutral *> way. *> *> A type of 'loose' integration is to have independent protocol *> definitions, but to define how they trigger each other - in *> particular, how the mobility protocol triggers NSIS to send *> refresh/modify/tear messages. A pair of implementations could use *> these triggers to improve performance, primarily reducing latency. *> (Existing RSVP modification consider the closer interaction of making *> the RSVP implementation mobility-routing aware, e.g. so it is able to *> localize refresh signaling; this would be a self contained aspect of *> NSIS.) This information could be developed for NSIS by analyzing *> message flows for various mobility signaling scenarios as was done *> in [21]. *> *> An even tighter level of integration is to consider a single protocol *> carrying both mobility and resource information. Logically, there are *> two cases: Wow. Well, yes, it's possible. but ... This is really a special case of the general issue that we faced when we first started RSVP design in 1992 -- how should routing and reservation relate? It was perfectly clear that we could do reservation by adding enough machinery to OSPF, but that did not seem to be a feasible approach. Besides the difficulty of getting it through the IETF, implemented, and deployed, there was a realistic fear the that resulting OSPF would fall over from sheer complexity. Besides, we would then have to modify EVERY routing protocol to do reservation, and that seemed totally unrealistic. So we kept them separate, but this led to ugly things like route pinning and QoR routing, and really making it work is still a largely unsolved technical problem. This subject is HARD. *> 1. Carry mobility routing information (a 'mobility object') in the *> resource messages, as is done in [23]. (The prime purpose in this *> approach is to enable crossover router discovery.) *> 2. Carry resource signaling in the mobility messages, typically as a *> new extension header. This was proposed in [25] and followed up *> in [26]; [27] also anticipates this approach. In our framework, we *> could consider this a special case of NSIS layering, with the *> mobility protocol playing the role of the signaling transport (as *> in 4.3.1). *> The usefulness of this class of approach depends on a tradeoff *> between specification simplicity and performance. Simulation work is *> under way to compare the performance of the two approaches in the *> case of RSVP and micromobility protocols. *> *> Other modes of interaction might also be possible. The critical point *> with all these models is that the general solutions developed by NSIS *> should not depend fundamentally on the choice of any particular *> mobility protocol. Especially if it has interdomain scope, tight *> integration would have major deployment issues (even loose *> integration could require NSIS implementations to hook into multiple *> different mobility protocols). Therefore, any tightly integrated *> solution should be considered out of scope of initial NSIS *> development, and even in the long term is probably only applicable if *> it can be localized within a particular part of the network. *> *> *> *> 5.3.5 Interaction with Fast Handoff Support Protocols *> *> In the context of mobility between different access routers, it is *> common to consider performance optimizations in two areas: selection *> of the optimal access router to handover to, and transfer of state *> information between the access routers to avoid having to regenerate *> it in the new access router after handover. The seamoby working group *> is developing solutions for these protocols for pure IP based *> networks (CARD[28] and CT[29] respectively); other networks, which Huh? We are developing signaling for "pure IP-based networks"; what other kind would be the subject of an IETF working group? *> use NSIS for resource signaling within the network, may use different *> types of solution. *> *> In this section, we consider how NSIS should interact with these *> functions, however they are implemented. Detailed solutions are not *> proposed, but the way in which interaction these functions is seen *> within the NSIS framework is described. NSIS should be able to *> operate independently of these protocols. However, significant *> performance gains could be achieved if they could be made to *> cooperate. In addition, the resource signaling aspects of these *> protocols could profitably use a common set of resource types and *> definitions, since they will probably be supporting the same overall *> signaling application. *> *> The question arises, what the mode of interaction should be: *> independent operation, NSIS triggering access router discovery and *> state transfer, or vice versa. The questions for the two cases seem *> to be independent. *> *> For access router discovery, a typical model of operation is that the *> mobile carries out an information gathering exercise about a range of *> capabilities. In addition, where those capabilities relate purely to *> the AR and mobile, there is no role for NSIS (its special *> functionality is not relevant). However, considering resource *> aspects, one aspect of the AR 'capability' is resource availability *> on the path between it and the correspondent, and NSIS should be able *> to fulfill this part. Indeed, this is effectively precisely the *> application considered in [26], where it is a sort of special case of *> resource signaling during handover. *> *> Therefore, a possible model of access router discovery/NSIS *> relationship is that some entity in a candidate AR triggers NSIS *> using resource and reservation information (including reservation id) *> from the current AR to find out about what would be available on the *> new path. Note that this should be a query rather than an actual *> reservation; this semantic could be included either in the NTLP or *> NSLP. *> *> The case of state transfer is more complex. There are two obvious *> options, corresponding to whether one transfers just signaling *> application state or NSIS state as well: *> 1. "State transfer triggering NSIS": A state transfer process passes *> the 'raw' resource state to the new AR. This triggers a new instance *> of NSIS to request that resource. *> 2. "NSIS using state transfer": NSIS transfers its own state *> information from the old to the new AR. It can then carry out the *> same update signaling as though it was a single 'virtual AR' which *> had just had a topology change towards the correspondent. (This is *> essentially the conceptual model of [21].) *> *> The first model is simpler, and maybe more in line with the basic *> state transfer expectation; however, it seems hard to avoid double *> reservations since the two NSIS protocol instances are not *> coordinated. Therefore, the second model seems more appropriate. An *> advantage of the 'virtual AR' model is that it ensures that the *> impact of the interaction is limited to the NSIS instances at ARs *> themselves, since the rest of the network must be able to handle a *> topology change anyway. *> *> Note that there is an open issue of who is responsible between the *> mobile and AR to decide that the state transfer procedures have not *> happened for whatever reason - e.g. because they were not even *> implemented - and take recovery action to have the mobile refresh *> reservations promptly. It appears this has to be an NSIS *> responsibility in the AR, and probably requires a custom notification *> message for this circumstance. *> *> 5.4 NSIS Interacting with NATs *> *> Because at least some NSIS messages will almost inevitably contain *> address and possibly higher layer information as payload (see section *> 4.5.1), we must consider the interaction between NSIS and address *> translation devices (NATs). As well as 'traditional' NATs of various *> types (as defined in [30]) very similar considerations would apply to *> some IPv4/v6 transition mechanisms such as SIIT [31]. *> *> In the simplest case of an NSIS unaware NAT in the signaling path, *> payloads will be uncorrected and the signaling will be for the *> incorrect flow. Applications could attempt to use STUN [32] or *> similar techniques to detect and recover from the presence of the *> NAT. Even then, NSIS would have to use a well known encapsulation *> (TCP/UDP/ICMP) to avoid being dropped by the more cautious low-end *> NAT devices. I *LIKE* it! Listen up, Melinda. We need NSIS over HTTP, clearly! *> *> A simple 'NSIS-aware' NAT would require flow identification *> information to be in the clear and not integrity protected. An *> alternative conceptual approach is to consider the NAT functionality *> being part of NSIS message processing itself, in which case the *> translating node can take part natively in any NSIS security *> mechanisms. Depending on NSIS layering, it could be possible for this *> processing to be done in an NSIS node which was otherwise ignorant of *> any particular NSIS signaling applications. *> *> Note that all of this discussion is independent of the use of NSIS *> for general control of NATs (and firewalls). This is considered in *> section 7.4. *> *> 6. Security and AAA Considerations *> *> A framework is meant to create boundaries for a later protocol and to *> describe the interaction between the protocol and its environment. *> Security issues usually turn out to have impacts in the interaction *> of these protocols and must therefore be appropriately addressed in *> such a framework. This section describes these general security *> issues, and in particular considers the interactions between NSIS and *> authentication, authorization and accounting. Together with *> authentication the protection of the signaling messages is addressed *> - namely replay and integrity protection. *> *> An initial analysis of the major security threats that apply in the *> typical of scenario where NSIS is expected to be used is given in *> [5]; these threats are described at the overall scenario level, in *> terms of the impact on users and networks. However, in any given *> scenario, NSIS will be just one part of the overall solution. *> Ultimately, the framework will need to define which of these threats *> need to be handled by NSIS (and which parts of NSIS) and which by the *> other components. Currently, we can only make initial scoping *> assumptions of this sort. *> *> 6.1 Authentication *> *> Authentication and key establishment for a signaling protocol should *> be seen as a two-phase process. The first-phase is usually more *> performance intensive because of a larger number of roundtrips, *> denial of service protection, cross-realm handling, interaction with *> other protocols and the likely larger cryptographic computation *> associated with it. As stated in section 4.3, this functionality *> could be provided externally to NSIS, e.g. by reusing a standard *> protocol which already included this functionality. *> *> At the end of this phase it should be possible to create or derive *> security associations that are usable for the protection of the NSIS *> signaling messages themselves. The functionality required here *> relates to (data origin) authentication (including integrity and *> replay protection) of individual signaling messages. Key *> establishment, rekeying, synchronization issues are issue that may be *> addressed here depending on the specific method. In any case the *> protection applied to each signaling message must be fast and *> efficient. *> *> When using cryptography to protect signaling messages, it is obvious *> that a node must be able to select the appropriate security *> association in order to be able to apply signaling message *> protection. This should just be a general point about endpoint *> identity issues. Hence the identifier must be available to the *> transmitting node. Regarding identities there is a need to support *> different identity types to enable the flexible usage of several *> signaling initiators and receivers. Supporting static configuration *> and dynamic learning of these identities should be provided. *> *> 6.2 Authorization *> *> Authorization information can be seen in an abstract form as "Can the *> resource requestor be trusted to pay for the reservation?". This *> abstraction is supported by the fact that reservations require some *> form of incentive to use some 'default' resource (or vice versa - *> penalty for not reserving too many resources). In general, the I think the sense of this sentence is reversed, else I am seriously confused. *> semantics of the authorisation will depend on the signaling *> application in use. The implication of this is that NSIS will not *> directly make authorisation decisions; instead, the authorisation *> information must be fed into the resource management function *> (section 5.1) which actually decides on the request. *> *> Some negotiation needs to take place to determine which node will *> take responsibility for authorising a resource request, the *> implication being that the same node will ultimately be accounted to *> for it. Such a negotiation needs to be flexible enough to support *> most currently deployed schemes (e.g. reverse charging, etc.) while *> keeping efficiency and simplicity in mind. This negotiation might be *> executed before starting resource signaling (assumed in section 4.2), *> although it could also be part of the NSIS signaling messages (as in *> some proposals dealing with charging and RSVP). Since information *> needs to be sent to the networks, some information needs to be *> included to provide the network with the necessary information to *> start the authorisation process. Hence fully opaque objects might not *> always be the proper choice. *> *> It is not clear if 'initiation' of a reservation is related to *> willingness to accept authorisation responsibility. (Current *> practices tend to assume that flow originators are responsible.) In *> any case, it seems unlikely that a domain will make a cost-incurring *> request of a peer domain without already having received a matching *> request from the peer in the other direction - in other words, *> requests must propagate between domains in the same direction as *> authorisation responsibility. Doesn't Reverse-Charging violate this? *> *> If this argument is correct, and if NSIS initiation and authorisation *> responsibility are decoupled, it must be possible for the *> authorisation responsibility to propagate both in the direction *> initiator->responder and vice versa. Also, if both [flow] sender and *> receiver initiation are possible, service descriptions must include *> information about the authorisation policy to be applied, which must *> be imposed consistently along the whole path. These issues should be *> analyzed to determine if 1, 2 or 4 alternative scenarios are possible *> and realistic. *> *> A second question is that of which entities actually authorise which. *> One end user must ultimately get authorisation for the request (this *> may or may not be assumed to be the NSIS initiator, see below). There *> are then two possible models for how this authorisation is done *> throughout the path. *> *> The first model assumes that each network along the path is able to *> authenticate and authorise the user directly. The implication for a *> signaling protocol is that the user credentials cannot be removed *> after the first hop and have to be further included in the message *> when forwarded to other networks. Every node along the path is then *> able to verify the user and to provide policy based admission *> control. *> *> The second model assumes that the user credentials are removed at the *> first hop. The first network knows the user identity requesting the *> resources but does not include this information further along the *> path. The first network can therefore be seen as acting on behalf of *> the originator to take responsibility to enable further reservations *> to be done along the path i.e. in particular to the next network *> only. This procedure is then applied on a hop-by-hop basis. *> *> Note that both models are independent of whether a traditional *> subscription based approach or an alternative means of payment (such *> as pre-pay on on-line charging by the visited network) is used. These *> issues only have an impact for the transmission of accounting records *> and for a requirement to execute an online verification whether a *> user still has sufficient credits/funds; therefore, these details do *> not affect NSIS operation. *> *> 6.3 Accounting *> *> It is obvious that accounting/charging is an important part for the *> success and the acceptance of a resource signaling protocol. Most of *> the thinking in this area is derived from the specific case of *> signaling for QoS; however, we make an initial working assumption *> that the same paradigm should apply to any signaling application for *> which accounting is necessary. We make the general assumption here *> that accounting records are generated by the resource management *> function based entirely on traffic measurements and processed in *> accordance with the authorisation information that was used in *> deciding to grant the request in the first place. This approach might be applicable in some cases, but it seems likely that charging will more often depend upon reservations, so that the signaling protocol will need to participate in the charging. *> *> Therefore, NSIS plays no further part in this activity; the *> accounting records are transmitted using the AAA infrastructure, and *> charging and billing for the overall service is carried out at some *> higher layer. This would include feedback to applications (and users) *> about total session cost (of which the network resource cost might be *> only a part). An open issue is whether a query (without actually *> making a reservation) to the network should also generate a *> chargeable event; this could be considered as an aspect of the *> service definition. *> *> 6.4 End-to-End vs. Peer Relationship Protection *> *> It is reasonable to assume that peer relationship security (with *> chain-of-trust) is used for most signaling environments relevant to *> NSIS. Especially the separation of signaling into different network *> parts (intra-domain within the access network, end-node to access *> network, intra-domain, and so on) and new proposals regarding *> mobility and proxy support show that traditional end-to-end signaling *> is not applicable in every environment (or possibly only in a minor *> number of environments). End-to-end security in a signaling protocol *> is actually problematic for two reasons: *> *> 1. Even if the messages use the address of the end-host (to support *> routing), the messages still have to be interpreted and modified *> along the path. *> *> 2. The only property that can be achieved by using end-to-end *> security is that one end-host can be assured that the other end-host *> included some parameters (possibly resource parameters) that have not *> been modified along the path. Nodes along the path usually do not *> have the possibility to cryptographically verify the protected *> message parts. If the two end-points negotiate which side has to pay *> for the reservation (or possibly how much and other parameters) *> within the signaling protocol then there is a need to protect this *> information. This leads to the question which protocols are executed *> before the signaling message exchange starts. If resource parameters *> and payment/charging related information are already exchanged *> beforehand as part of a separate protocol (possibly SIP) then there *> at the NSIS level basis. In most cases an opaque token to link the *> different protocols may be sufficient. *> *> 7. NSIS Application Scenarios *> *> This section considers various application scenarios or deployment *> configurations for NSIS. Our goal is that an NSIS protocol designed *> according to the framework presented in the previous sections should *> be able to support these scenarios if implemented appropriately; *> therefore, this section does not form part of the framework *> definition, but rather provides examples of how NSIS can be used to *> do something interesting. In the long term, some of this material may *> be contained in specific NSIS applicability statements. *> *> 7.1 NSIS and Existing Resource Signaling Protocols *> *> It is hoped that NSIS could eventually achieve widespread use for *> resource signaling. However, it is bound to have to inter-operate *> with existing resource signaling protocols at least during transition *> and possibly long term. The prime example for QoS is RSVP, although *> other proprietary or domain specific protocols (e.g. bandwidth broker *> related) may also be considered. A related issue is that NSIS will be *> only one part of the solution: it will always need to interwork with *> other resource-related protocols (e.g. COPS). Policy control, ... -- need refs here. *> *> Analyzing the constraints on NSIS that come from these requirements *> is hard before further refinement of the framework has been carried *> out and critical assumptions pinned down. However, we can identify *> various modes of interoperation, and the attributes of the framework *> that will make them easy. *> *> Firstly, we allow for NSIS use over a 'long range', in conjunction *> with a different protocol locally (e.g. intra-domain); or, the two *> roles could be reversed. This is actually very similar to the case of *> use of NSIS layered over itself (section 7.5). In the case where the *> 'inter-layer' interaction is mediated via resource management, the *> same should approach should work with non-NSIS protocols. What needs *> to be validated here is whether NSIS layering requires the exchange *> of NSIS specific information between the layers. *> *> A second issue is that NSIS should be deployable within an *> environment without radical changes to supporting resource (or AAA) *> related protocols. The main issue here is that NSIS should be *> flexible in its ability to support different service definitions (and *> possibly flow classifications). This is already one of the main goals *> of the framework presented here. *> *> The final point is that it should be possible to use NSIS over one *> network region, concatenated with another protocol over an adjacent *> region. The main issue here, apart from the flexible service and flow *> capabilities already mentioned, is that NSIS should be adaptable in *> what it assumes about signaling paths (e.g. to interwork with both *> path-coupled and decoupled solutions), and in initiation paradigms *> (e.g. to interwork with sender and receiver initiated solutions). *> *> 7.2 NSIS Supporting Centralized QoS Resource Management *> See the comments on RMF in my overview message. *> One area of application for the NSIS protocol is for QoS resource *> reservation and provisioning. The NSIS protocol may be used to *> provide intra-domain or inter-domain QoS bandwidth reservation setup *> by means of its interaction with the RMF. In what follows we assume *> that the NEs are colocated with an admission control entity that has *> a logical (abstract) view on the resources managed by the RMF, as *> described in section 5.1. *> *> The NEs in a domain can interface with an RMF managing the complete *> domain, in which case, the abstract topology view provided between *> NSIS and RMF can be formalized as a Service Level Agreement (SLA). *> This situation is depicted schematically in Figure 7. It is not clear to me that this makes sense. However, if you are going to talk about this, you need to reference the SLS work draft-tequila-sls-00.txt. *> *> +----+ NSIS +-----+ NSIS +----+ *> | NI |============| NF |=============| NR | *> +----+ +-----+ +----+ *> | *> | SLA *> | *> +------+ *> | RMF | *> +------+ *> *> Figure 7: Resource Reservation using RMF as a Server to NSIS *> *> In case of centralized RMF, the SLA or its technical part, the *> Service Level Specification (SLS) [33] specifies the resource *> guarantees that the RMF needs to provide to the NF. These guarantees *> apply between one or more ingress and egress points of the network. *> The SLS also specifies the availability and reliability of the *> service. In the case of QoS signaling, it may refer to a bandwidth *> service with certain performance guarantees regarding delay, jitter *> or packet loss. The SLS interface can be automated by means of an SLS *> negotiation protocol. This allows for more dynamical SLS *> modifications and the exchange of notification messages with the NF. *> These can for instance be used to provide monitoring feedback from *> the RFM to the NF. *> *> The decoupling of NSIS signaling and network management by means of *> an SLS has some attractive properties: *> *) It allows a Network Provider to easily share the use of its *> infrastructure between several Service Providers using NSIS signaling *> to provide their service. *> *) It allows a clear separation between resource provisioning and *> management and reservation signaling and admission control. *> *) It relieves the NF from several tasks, making it potentially more *> scalable in the core of the network. *> *> The NF can perform either per-flow or per-class admission control *> decisions based on the requested QoS information and on the *> reservation state it keeps regarding active flows (or classes). *> Keeping per-flow state may be required for policing, *> accounting/billing and explicit reservation teardown. These functions *> are mandatory in the access or edge of the network. Conveniently, *> this is also where the processing needed to maintain per-flow state *> will remain manageable. In the core, this approach may not scale very *> well and per-class state may be used as an alternative that is very *> scalable and allows for a lightweight processing of signaling *> messages. With per-class state, however, we lose the ability to *> directly notify the NI in case of unsolicited network events because *> the affected flows cannot be identified. Instead, the NI needs to be *> indirectly notified in response to a refresh message which in turn *> mandates the use of soft-state with separate messages or message *> structure for requests and refreshes. *> *> The RMF can execute its network provisioning functions according to *> its internal policies. In the easiest case, it may run an *> overprovisioned network with only monitoring capabilities in order to *> follow up on the delivered performance. In more complex scenarios, it *> may use a whole array of network optimization tools in order to *> deliver and maintain service quality according to the SLS. This may *> require network monitoring, the installation and use of appropriate *> protection mechanisms and providing feedback regarding actual traffic *> performance to the NSIS entity. *> *> Alternatively, the NSIS protocol may be used for resource *> provisioning. In that case, the RMF acts as a client towards the NSIS *> protocol, as a particular "application" triggering an NI for *> resources in the network. This situation is depicted in Figure 8. *> *> +------+ *> +----------| RMF |----------+ *> / +------+ \ *> / \ *> / \ *> / \ *> +----+ NSIS +-----+ NSIS +----+ *> | NI |============| NF |=============| NR | *> +----+ +-----+ +----+ *> *> Figure 8: NSIS for Resource Provisioning *> *> In this case the RMF is providing traffic classification and *> conditioning functions. An example of such functionality is described *> in [34]. The packet "classifiers" select the packets in a traffic *> stream based on the content of some portion of the packet header. The *> traffic "conditioner" performs metering, shaping, policing, *> scheduling and/or re- marking of packets to ensure that the traffic *> entering a node conforms to a certain predefined policy. *> *> 7.3 NSIS Supporting Distributed Resource Management *> *> Section 7.2 described the situation where NSIS is supporting a *> centralized RMF. This section introduces the situation where NSIS is *> supporting a distributed RMF. When the RMF is distributed in the *> network, a protocol for communication with the NI, NF, NR may not be *> required. In this case the RMF is providing traffic classification *> and conditioning functions; an example of such functionality is *> described in [34]. Figure 9 shows how a distributed RMF could *> interact with the NSIS protocol. *> *> +----+ NSIS +-----+ NSIS +-----+ NSIS +----+ *> | NI |==========| NF |====...====| NF |==========| NR | *> +----+ +-----+ +-----+ +----+ *> +----+ +-----+ +-----+ +----+ *> |RMF | | RMF | | RMF | |RMF | *> +----+ +-----+ +-----+ +----+ *> *> Figure 9: Distributed RMF as a server for NSIS *> This figure seems more correct than Figure 1 -- and should probably replace Fig 1. *> 7.4 NSIS for Middlebox Signaling *> *> As well as the use for 'traditional' QoS signaling, it should be #### Another possible application of the signaling protocol to set up #### flow-related state in middleboxes (firewalls, NATs, etc.) *> possible to use NSIS to set up flow-related state in middleboxes *> (firewalls, NATs, and so on). Requirements for such communication are *> given in [35], and initial discussions of NSIS-like solutions are *> contained in [36], [37] and [38]. A future version of this document *> may contain more details on how an NSIS should be used for this type *> of signaling application. *> *> 7.5 Multi-Level NSIS Signaling *> Multi-level signaling might be a good idea, and there is a literature on it going back to Banerjea at Berkeley 10 years ago (the Tenet system), as well as Lixia Zhang's more recent mulit-level signaling model. A little bit of scholarship would pay dividends here. This section feels like too much top-down abstraction and boxes with lines, and not a clear intellectual model that fits the real world of networking. I think the real world connection is lurking, but it is hidden in layerist abstraction here. *> This section describes a way of separating the NSIS signaling *> protocol into more than one hierarchical level. In this section three *> levels of hierarchy are considered (see Figure 10); however, the *> approach is quite general to more (or fewer) levels: the important *> issue is the use of NSIS at more than one level at all. *> *> The lowest hierarchical level ("level 1") provides basic resource *> management functionality related to scalable, simple and fast soft *> state maintenance and to transport functions, such as reliable *> delivery of signaling messages, congestion control notification and *> load sharing adaptation. Soft state that is maintained by this level *> is usually per traffic class based. *> *> The second hierarchical level ("level 2") is more complex than level *> 1 as regards soft state maintenance. Soft state maintained by this *> hierarchical level is usually per flow. Note that this level, like *> level 1, also supports transport functions. When an NSIS edge-to-edge *> multi-domain protocol is used, level 2 stretches beyond domain *> boundaries and is applied on all the edges of the domains that are *> included in the multidomain region. *> *> The third hierarchical level ("level 3") includes a set of upper- *> level signaling functions that are specific to particular signaling *> applications. Such functions could, for example, be security, policy, *> billing, etc. *> *> As shown in Figure 10, the three hierarchical levels might be applied *> on different NSIS entities. *> *> This three-level architecture for NSIS signaling can be provided by *> using: *> *) a single end-to-end NSIS protocol that supports all three *> hierarchical levels *> *) two independent NSIS protocols: Level 3 is supported by an end- *> to-end NSIS protocol, and levels 1 and 2 are supported by another *> edge-to-edge NSIS protocol. *> *> *> *> *> |-----| |-------| |-------| |-----| *> |level|<--| level |<--------------------------| level |<->|level| *> | 3 |<--| 3 | | 3 |<->| 3 | *> |-----| |-------| |-------| |-----| *> | | | | | | | | *> | | |-------| |-------| | | *> | | | level |<------------------------->| level | | | *> | | | 2 | | 2 | | | *> | | |-------| |-------| | | *> | | | | | | | | *> |-----| | | | *> ------- -------| |-------| |-------| |-----| *> |level|<->| level |<->| level |<->| level |<->| level |<->|level| *> | 1 |<->| 1 |<->| 1 |<->| 1 |<->| 1 |<->| 1 | *> |-----| |-------| |-------| |-------| |-------| |-----| *> NI NF NF NF NF NR *> (edge) (interior) (interior) (edge) *> *> Figure 10: Three level architecture for NSIS signaling *> *> The components in the scenario are as follows: *> *) NI (NSIS Initiator): can be an end-host or a proxy and can *> process and use the "level 1" and "level 3" protocol components *> *) NR (NSIS Responder): can be an end-host or a proxy and can *> process and use the "level 1" and "level 3" protocol components *> *) NF (NSIS Forwarder) (edge): can be a Diffserv edge, MPLS edge, *> etc. It can process and use the "level 3", "level 2" and "level 1" *> protocol components. Usually, "level 2" provides an interworking *> between "level 1" and "level 3" protocol components. *> *) NF (interior): can be any router within a domain. It can process *> and use only the "level 1" protocol component. The "level 3" and *> "level 2" protocol components are not processed (used or checked). *> *> The hierarchical level separation can be provided by supporting a *> hierarchical object structure. In other words, the NSIS protocol *> objects should be structured and positioned within the NSIS messages *> in a hierarchical way, i.e., first the "level 1" objects, then the *> "level 2" objects and finally the "level 3" objects. *> *> 8. Open Issues *> *> The following issues are currently open points within the framework. *> They are summarized here to provide a single overview. *> *> 1. It is not clear which of the NI, NF and NR can modify or release *> existing reservations (this is essentially an authorisation issue). *> (Section 3.3.2.) *> *> 2. It is not clear whether NSIS entities relate to each other only *> locally (peer-peer) or whether longer distance, non-local *> interactions and state have to be managed and stored. (Section *> 3.3.3.) *> *> 3. NSIS messages could be addressed either explicitly (to the *> neighboring peer) or implicitly, using the flow endpoint addresses. *> (Section 3.3.4.) If this is a question, the answer is "yes." ;-) *> *> 4. It is not clear where to draw the boundaries between the NTLP and *> NSIS signaling layer, and how to establish the extent to which the *> requirements of the diverse signaling applications considered for *> NSIS should influence NTLP functionality. (Section 3.3.5.) *> *> 5. If NSIS has explicit acknowledgement and notification messages, *> it is open whether they should relate to anything beyond the *> immediate peer relationship. (Section 3.3.6.) *> *> 6. To function as part of a complete system, the NSIS protocol may *> need to be supported by extensions to other protocols. These *> extensions are still to be identified. (Section 4.2.) *> *> 7. The NSIS protocol could be constructed on the services offered by *> lower layer protocols, but the dividing line between NSIS and these *> lower layers is not fixed. Use of standard lower layer protocols may *> be difficult if 'end-to-end addressing' (see section 3.3.4) is used. *> (Section 4.3.1.) It took me awhile to understand the last sentence; you should clarify it. *> *> 8. It is commonly expected that a future resource signaling protocol I am glad to know that I am not "common". ;-) *> would need to use abstract reservation identifiers. However, the *> precise properties needed of these identifiers are unclear, and *> enabling their secure use may be hard. (Sections 4.5.2 and 5.3.2.) *> *> 9. Use of some routing techniques (e.g. load sharing or QoS *> routing), even in remote parts of the network, could be incompatible *> with naive use of end-to-end addressing. (Sections 5.2.1 and 5.2.2.) *> Well, YES! So the conclusion, which should be pointed out clearly in section 5.2, is that path-coupled signaling requires the *intelligent* use of E2E addresing. *> 10. The correct flow identification semantics need to be defined in *> the case where mobility encapsulations might make it ambiguous which *> addresses to use. (Section 5.3.1.) *> *> 11. The interactions between mobility and resource signaling during *> path updating need to be further analyzed, especially from the point *> of view of combined overall latency. (Section 5.3.2 and 5.3.3.) *> *> *> *> ... Whew! Hope some of this helps. Bob Braden ----- End Included Message ----- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 14 04: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 EAA13577 for ; Thu, 14 Nov 2002 04:02:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAE94bE13685 for nsis-archive@odin.ietf.org; Thu, 14 Nov 2002 04:04: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 gAE94Xv13662; Thu, 14 Nov 2002 04: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 gAE93lv13623 for ; Thu, 14 Nov 2002 04:03:47 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13561 for ; Thu, 14 Nov 2002 04:01:00 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gAE8thB06721; Thu, 14 Nov 2002 09:55:43 +0100 To: nsis@ietf.org, nsobs@ccrle.nec.de X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 14 Nov 2002 09:18:10 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/14/2002 10:03:29 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [NSIS] new draft Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi all, We have submitted a draft entitled "An architecture for a gradual deployment of end-to-end QoS on an Internet-wide scale (Virtual Service-aware Network)" http://www.ietf.org/internet-drafts/draft-declercq-vsn-arch-00.txt) This document introduces Virtual Service-aware Networks (VSNs) as a solution for inter-domain resource reservation with Quality-of-Service (QoS) on an Internet-wide scale. The proposed approach benefits from (but is not restricted to) VPNs and off-path signaling, which enables the gradual introduction of this architecture without changing the existing routers. Any comment to the draft and the proposed architecture is very welcome. Thanks, Sven _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 14 04:02: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 EAA13590 for ; Thu, 14 Nov 2002 04:02:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAE94d213697 for nsis-archive@odin.ietf.org; Thu, 14 Nov 2002 04:04:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAE94Zv13678; Thu, 14 Nov 2002 04:04:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAE93mv13627 for ; Thu, 14 Nov 2002 04:03:48 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13560 for ; Thu, 14 Nov 2002 04:01:00 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gAE8tcB06590; Thu, 14 Nov 2002 09:55:38 +0100 Subject: Re: [NSIS] General comments on draft-ietf-nsis-fw-01.txt To: Bob Braden Cc: nsis@ietf.org, braden@ISI.EDU X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 14 Nov 2002 09:11:23 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/14/2002 10:03:24 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Bob, Thanks for your comments. I have some remarks/questions inline. Thanks, Sven Bob Braden @ietf.org on 13/11/2002 20:36:06 Sent by: nsis-admin@ietf.org To: nsis@ietf.org cc: braden@ISI.EDU Subject: [NSIS] General comments on draft-ietf-nsis-fw-01.txt I finally found time to comment on the Framework draft. Sorry this comes so late. A separate message contains interleaved detailed comments, issues, questions, and disagreements. This message distills out some general comments. The Framework document represents a substantial body of work with much to recommend it. I know from experience how much work is represented here, and the authors deserve our praise and thanks. However, I also believe that considerable more work will be needed. First, a somewhat philosophical comment. My most general uneasiness with the present document is that it seems at times to float in a void. It seems a bit too top-down in flavor at times, without enough grounding in the real Internet issues. This gets better through the document, so that I generally liked sections 4, 5, and 6 much better than the eaerlier sections. It also seems a bit disconnected from the significant previous history of Internet signaling. Many of the technical issues of Internet signaling have in fact been explored in the IETF, principally by the RSVP working group (although not all of the conclusions made it into the existing RSVP v1 RFCs). Many readers will be familiar with at least the general concepts of RSVP, and it would be very helpful if the document was explicit, at least in a parenthetical way, about places where NSIS is taking a new tack, as well as places where it is covering the same ground. In a few places, using existing terminology where it fits would also be helpful. Now more specific general comments ;-) 1. I believe that the document would gain increased depth and credibility if it had a few more references to important and relevant academic papers. Particular examples might include YESSIR, Lixia's multi-level model, or (a small selection out of the corpus of) papers about mobile resource reservations. 2. There is a lot of good material and specific discussion, but there is some redundancy. It probably needs a serious hack with a text editor, moving blocks of text around and deleting redundant material. (see detailed comment message for examples.) 3. I would like to suggest that the only occurrence of the 4-letter term "NSIS" in this document should be in the combination "NSIS Working Group". All other occurrences of NSIS should be replaced by something else ... e.g., "Internet signaling" or "signaling" or ... whatever works in the particular context. Another useful term is "suite", as in a "suite of signaling protocols". Curiously, the word "node" almost never occurs in this document, yet it is fundamental. Signaling can be described abstractly, but that has to map into real messages sent between real nodes -- end systems, routers, and middleboxes. This may be just a stylistic thing. 4. The document tends to say, "Oh, by the way, this is not *just* about QoS", and then shortly falls into QoS-oriented terminology. I think this is the wrong orientation. It should rather be: "This is about all forms of path-related Internet signaling, such as QoS setup and control of middleboxes." A deeper consequence of this is the need to be quite precise about terminology, to make sure it is sufficiently general. What is the purpose of "signaling"? I generally use the Computer Sciency phrase, "to establish state in network nodes". The document often uses the term "resource request" for roughly the same concept (though it is not consistent.) At first I thought "resource request" should be replaced because it is too QoS-specific. However, it seems more in keeping with the existing document to simply define "resource request" in a general way as equivalent to setting up state, using a very general notion of what we mean by "resource". I think this can be made to work, but it needs a careful paragraph in the Introduction and strict care to always use this term. You will find a number of detailed suggested changes in this direction in my detailed comments. 5. At many points, the Framework document seems to assume a simplistic model of resource reservation -- that it is necessarily one-pass and can be achieved by a one-way flow of signaling packets along the data flow path. This omits the potentially important cases that require two-pass algorithms, or those that use one-pass-with-advertising (e.g., the IntServ Guaranteed service.) The WG should beware of simplistic assumptions. This shows up most directly in the terms NI and NR, whose semantics are sometimes confusing. Of course, *I* prefer the abstractions p-src and p-dest that I introduced in my 2level document ;-), but perhaps NI and NR can be made to work. However, that will require careful definition and usage. For example, RSVP v1 depends upon signaling in both directions, using both Path and Resv messages. So, for RSVP v1, both sender and receiver act as both NI and NR. Some of the discussion does not seem to encompass this generality. 6. The fundamental architectural picture in Figs 1 and 4 seems at first blush to be obvious, but the more I think about it, the more uncertain I am. The idea of a "co-located NI&NF" seems to conceptually define what you expect to be in an end system doing QoS signaling using the new protocol (and indeed that is exactly what RSVP v1 assumed). In particular, an Internet end system has to have at least a primitive routing/forwarding function, because it may be multihomed and/or have multiple first-hop routers. Also, for QoS setup, at least, it is generally necessary to have an (inner-)RMF in the end system as well as in the routers. (as shown in figure 9, which contradicts Figure 1!) These considerations probably hold even if the NI is not an end system. In fact, now that I think of it, it seems that there "co-located NI&NF" will be the normal case, except when a proxy is the NI. Iin practice the NI and NF functions will hopefully be only a single protocol entity in the end system. You can DESCRIBE it logically as two connected conceptual boxes, but this may not be very helpful to the implementor or in detailed design. In other words, the seemingly plausible picture conceals a deep issue of modularity and interface placement. Even if we decide that the figures as drawn at the best model, some discussion is needed about how this model maps into the real world. 7. The path-coupled/path-decoupled dichotomy is not all there is. Thinking about this space, I was led to introduce a different dichotomy, "path-related" vs. "path-unrelated". The NSIS WG is primarily focusing on path-related & path-coupled signaling, but some would like to also handle path-related & path-decoupled signaling. However, there is a 3rd class of signaling that has no direct relationship to any path; I called this path-decoupled. It might for example be used to configure routers in a domain. This is still signaling, but not the kind we intend to do in NSIS. 8. The text tends to imply the model of a signaling message passing from NI to NR through NFs undisturbed, rather like IP packets passing through routers. (See for example the first sentence of section 5.1) In some cases this may be the wrong conceptual model. In RSVP, signaling is best thought of as hop/hop; each hop propogates state in each direction, to keep certain invariants true. Also, refresh messages are generated independently and asyncronously at each hop. It is true that hop/hop action is forced by support for multicast, with its merging, so it may not be directly relevant to NSIS. However, there may be other signaling applications that will best be implemented as hop/hop signaling. [Sven] Would it be improved if we were more stringent about the NTLP/NSLP separation throughout the document. More emphasis is placed on this in the current version but maybe not enough throughout the text. I believe the framework should talk about both layers. I also think that the focus on the hop-by-hop aspect may be different for both layers (more for NTLP and less for NSLP that is). Assuming that NSLP is what contains the description of what actually needs to be reserved or done, it is reasonable to describe the interaction with RMF more from the NSLP viewpoint. 9. Sections 5.1 and 7.2 (which are somewhat redundant) seem foggy to me. For one thing, an RMF may be specific to one or more signaling applications, and there may be many distinct RMFs in a single node. [Sven] I agree. On the other hand, if an RMF is specific to a signalling application, the complete picture could be assembled from many of the current picture in parallel. Also, Figure 4 (which is repeated as Figure 7) and Figure 8 depict two quite different kinds to things [I would call them "entities", but you've used up that word ;-)], and it is not clear to me that you can usefully encompass both in a common abstraction. I see two kinds of things: an inner-RMF, which is the interface to the local node's [Sven] The idea was to clarify that there are indeed to different types of interactions with the RMF. On the one hand, the RMF may just be a server which assists in performing admission control for locally controlled resources (what you call the inner-RMF). On the other hand, it may trigger a new layer of (local) NSIS signalling. This is what you call the outer-RMF and what is depicted in figure 8. The picture may look a bit 'centralized' but it essentially expresses NSIS nesting where the RMF can be either client or server. I see "inner-RMFs" (Figs 4 & 7) that are local interfaces to the traffic control and admission control mechanisms of the forwarding plane. The WG should look into how an inner-RMF relates to the FORCES work of the IETF. Note that when an inner-RMF is a server, it may supply information to the NE as well as accept control state. Examples are admission control decisions and the Adspec machinery of RSVP v1. [Sven] I fully agree. Then there are "outer-RMFs" (Figure 8), which seem to have quite different characteristics. This section to be an attempt to bring the bandwidth broker under the NSIS umbrella, but this may/may not fall into our chartered area. [Sven] It does cover bandwidth brokers but it is certainly not restricted to that. There is no argument that bandwidth brokers are currently not the priority for the NSIS WG but it is also agreed that the framework should/may have a somewhat broader scope. Finally, it is far from obvious to me that the NF/RMF interface corresponds to an SLA. [Sven] I think it depends on where you see the admission control. If you see this as part of or colocated with the NF (i.e. handling of NSLP) then you can think of the RMF as providing an amount of capacity (e.g. the link bandwidth for a certain class of service) in which the NF does admission control. _____________________________________ Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 14 05:41: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 FAA15066 for ; Thu, 14 Nov 2002 05:41:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEAhUD19498 for nsis-archive@odin.ietf.org; Thu, 14 Nov 2002 05:43: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 gAEAhSv19490; Thu, 14 Nov 2002 05:43: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 gAEAgdv19446 for ; Thu, 14 Nov 2002 05:42: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 FAA15050 for ; Thu, 14 Nov 2002 05:40:03 -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 gAEAgbY63302; Thu, 14 Nov 2002 11:42:37 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id DF94065BAE; Thu, 14 Nov 2002 11:41:38 +0100 (CET) Date: Thu, 14 Nov 2002 11:41:40 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Bob Braden , nsis@ietf.org Subject: FW Bob's Point 5 (was Re: [NSIS] General comments on draft-ietf-nsis-fw-01.txt) Message-ID: <6961930.1037274100@[192.168.102.207]> In-Reply-To: <200211131936.TAA08169@gra.isi.edu> References: <200211131936.TAA08169@gra.isi.edu> X-Mailer: Mulberry/2.2.0 (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: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > 5. At many points, the Framework document seems to assume a simplistic > model of resource reservation -- that it is necessarily > one-pass and can be achieved by a one-way flow of signaling > packets along the data flow path. This omits the potentially > important cases that require two-pass algorithms, or those that > use one-pass-with-advertising (e.g., the IntServ Guaranteed > service.) The WG should beware of simplistic > assumptions. > > This shows up most directly in the terms NI and NR, whose > semantics are sometimes confusing. Of course, *I* prefer the > abstractions p-src and p-dest that I introduced in my 2level > document ;-), but perhaps NI and NR can be made to work. > However, that will require careful definition and usage. For > example, RSVP v1 depends upon signaling in both directions, > using both Path and Resv messages. So, for RSVP v1, both > sender and receiver act as both NI and NR. Some of the > discussion does not seem to encompass this generality. > Bob, I think we cover 80% of the relevant cases of reservation styles with a simple one-pass scheme. Concerning the NI/NR terms. I like the NI, because it does not say something about who is performing reservations, but it is driven by somebody initiating the whole thing. Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 14 10:07: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 KAA21209 for ; Thu, 14 Nov 2002 10:07:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEF9X202498 for nsis-archive@odin.ietf.org; Thu, 14 Nov 2002 10:09: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 gAEF9Vv02491; Thu, 14 Nov 2002 10:09: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 gAEF1ev01601 for ; Thu, 14 Nov 2002 10:01:40 -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 JAA20987 for ; Thu, 14 Nov 2002 09:59:03 -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 gAEF1QsA023283; Thu, 14 Nov 2002 07:01:26 -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 AAU43620; Thu, 14 Nov 2002 06:56:56 -0800 (PST) Message-Id: <200211141456.AAU43620@mira-sjc5-4.cisco.com> To: "Hancock, Robert" cc: Bob Braden , nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] General comments on draft-ietf-nsis-fw-01.txt In-Reply-To: Message from "Hancock, Robert" of "Thu, 14 Nov 2002 00:21:20 GMT." <76C92FBBFB58D411AE760090271ED41805DF5E31@rsys002a.roke.co.uk> Date: Thu, 14 Nov 2002 10:01:35 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , On point 6 (message flows), complicating features include whether or not part of the signaling problem you're trying to solve include topology - that is to say, some NFs are more interesting than other NFs, based on their topological relationship. The most obvious cases of that would be ones in which you're asking something in particular of an outermost NF but you don't have any way of knowing where that is and you're asking the signaling protocol to handle it for you. For example, in the case of NAT, you're using the signaling protocol to do 1) installation of NAT table state, and 2) reporting on installed state (so that an application that uses embedded addresses can know the correct address with respect to the application peer). In the case of tunnel endpoints (a subset of security gateways, for example, but they may be other types of tunnels) you probably want to find the furthest tunnel endpoint along the path, but you may be interested in finding the closest, or the one that has the most appropriate set of other (non-topological) attributes. Note that these have slightly different messaging requirements. In the case of NAT it may be sufficient to store state in a forward direction and then have the receiver return a result message. In the case of signaling gateways, however, each NF can't store state in a forward direction because (unlike NAT) no decision can be made about who gets to terminate the tunnel until a complete picture of the topology/capabilities/whatever is accumulated. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 14 10:55: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 KAA22305 for ; Thu, 14 Nov 2002 10:55:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEFvMW04959 for nsis-archive@odin.ietf.org; Thu, 14 Nov 2002 10:57: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 gAEFvJv04951; Thu, 14 Nov 2002 10:57: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 gAEFupv04926 for ; Thu, 14 Nov 2002 10:56:51 -0500 Received: from tms002bb.han.telia.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22278 for ; Thu, 14 Nov 2002 10:54:13 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from tms041mb.han.telia.se ([131.115.230.167]) by tms002bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Nov 2002 16:56:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Detailed comments on draft-ietf-nsis-fw-01.txt Date: Thu, 14 Nov 2002 16:56:46 +0100 Message-ID: <1BF8A5964E4EFA41A094B835FCA71291F7B889@TMS041MB.tcad.telia.se> Thread-Topic: [NSIS] Detailed comments on draft-ietf-nsis-fw-01.txt Thread-Index: AcKLkypUl8upi3NcR9mWp7mjlTZCFAAXZZnA To: , X-OriginalArrivalTime: 14 Nov 2002 15:56:46.0764 (UTC) FILETIME=[6F7046C0:01C28BF6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAEFutv04927 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Bob, I noticed that this is the second time you refer to the interaction between routing & signaling by saying that there is "a LOT more to say"... could you please expand on what more you see is missing and be quite explicit about your points? I see several interactions possible between routing & signaling. For example, if you look into the advertisement needed for GQoS in IntServ, which forced additions to RSVP (one-pass with advertisement). An alternate design would be to rely on routing to carry the information (this information is very close to routing-information anyway) and only use signaling to install (resource) state in the routers. Routing could make use of additional information (such as, but I am not proposing in any way, the path characteristics collected in RSVP) when choosing paths. Hm, I guess this would be called non-traditional layer 3 routing... Another interaction is what RSVP has chosen to do with the PATH messages, ie path state setup. This could be seen as a very non-traditional way of doing routing, since you effectively route-pin the RESV messages (at least as long as the path-state is there, right). So in effect, RSVP has two functions that could be generalised, path state setup and resource state setup. These are two distinct state manipulations, that could be described seperately. (ok, once again perhaps this leads off the topic, since it is a non-traditional way of layer 3 routing). Some have argued that route-pinning is required (at least beneficial) for load balancing algorithms in the network, since the problem to control stability has been claimed to be simpler. Old paths could be kept for already established flows, while new traverse the new path... ok, very untraditional L3 routing, but interesting thought. A third interaction that touch the previous is state manipulation and its relation to a path. If two routers that have a state that is shared between them (for example RESV-state), and it would be possible to forward packet between them and reach the end-station, if L3-routing changes the route for the flow (such that one end is not really on-path any longer) should you tear down the state? Yes is the obvious answer - however, not doing this causes less resource request and perhaps less denials for established reservations in the network. Not at all a trivial question, but changes L3 routing... once again off topic, I assume. So what interactions between _traditional_ L3-routing and signaling do you see? I am especially interested in your experiences from RSVP-development since you must have discussed these issues before. Best regards, Anders > *> 5.2 IP Routing Interactions > *> > *> Several situations may occur when routing diverges > from standard > *> layer 3 routing. These are summarized in the sections below. > > There is a LOT more to say about routing interactions, even with > "standard layer 3 routing"!! _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 14 15:50: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 PAA00409 for ; Thu, 14 Nov 2002 15:50:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEKqJW24169 for nsis-archive@odin.ietf.org; Thu, 14 Nov 2002 15:52:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEKqHv24133; Thu, 14 Nov 2002 15:52:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEKpEv24049 for ; Thu, 14 Nov 2002 15:51:14 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00354 for ; Thu, 14 Nov 2002 15:48:34 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gAEKp7a08628 for ; Thu, 14 Nov 2002 12:51:07 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id UAA08513 for nsis@ietf.org; Thu, 14 Nov 2002 20:51:07 GMT Date: Thu, 14 Nov 2002 20:51:07 GMT Message-Id: <200211142051.UAA08513@gra.isi.edu> To: nsis@ietf.org Subject: RE: [NSIS] Detailed comments on draft-ietf-nsis-fw-01.txt X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> Bob, *> *> I noticed that this is the second time you refer to the interaction between routing & signaling by saying that there is "a LOT more to say"... could you please expand on what more you see is missing and be quite explicit about your points? *> I don't want to take time right now, but I can give you some references. Unfortunately, I don't know of a single clear reference that covers the subject, but there are a number of relevant fragments from which one can piece together the entire story. Here then are some relevant references: Interdomain Multicast Routing Support for Integrated Services Networks Zappala, D., Braden, B., Estrin, E., and S. Shenker, Internet Draft, March 26, 1997. (This draft concentrates on the multicast problem because it is harder (;-)) but much of it is directly relevant to unicast routing.) RSRR: A Routing Interface For RSVP Zappala, D., Kann, J., Internet Draft, June 1998. The Design of the RSVP Protocol, Braden, R., Estrin, D., Berson, S., Herzog, S., and D. Zappala, ISI Final Technical Report, July 1996. (The discussion on page 4.) The various IETF projects on QoS routing, e.g., RFC 2676. Note: all of the above, except for the last, are available on the RSVP web page (www.isi.edu/rsvp) under Publications. I hope this will help answer your question. Bob Braden ----- End Included Message ----- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 14 17:25:49 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 RAA03141 for ; Thu, 14 Nov 2002 17:25:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEMRxB30014 for nsis-archive@odin.ietf.org; Thu, 14 Nov 2002 17:27: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 gAEMRvv30006; Thu, 14 Nov 2002 17:27: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 gAEMOjv29896 for ; Thu, 14 Nov 2002 17:24:45 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03046 for ; Thu, 14 Nov 2002 17:22:04 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAEMO7O23261 for ; Fri, 15 Nov 2002 00:24:07 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 15 Nov 2002 00:23:34 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 15 Nov 2002 00:23:34 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 15 Nov 2002 00:23:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 15 Nov 2002 00:23:34 +0200 Message-ID: Thread-Topic: [NSIS] Key management - Nat involvement Thread-Index: AcKLKPRfy+kD8bQoTPaC9ahU5DlbJgAe9Qyw To: X-OriginalArrivalTime: 14 Nov 2002 22:23:34.0270 (UTC) FILETIME=[7830A9E0:01C28C2C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAEMOjv29897 Subject: [NSIS] Updated agenda Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Tuesday November 19, 2002 1300-1400 Afternoon Session I WG Status, charter discussion - chair 20 min Terminology Discustion - Robert Hancock Requirements - Marcus Brunner - 20 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-05.txt Wrap-up - 10 minutes WEDNESDAY, November 20, 2002 0900-1130 Morning Sessions Framework Discussion - 50 minutes Next Steps in Signaling: Framework - Robert Handcock - (15 min) http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-00.txt Trade-offs and open issues with path discovery and transport - Henning Schulzrinne - (15 min) http://www.ietf.org/internet-drafts/draft-schulzrinne-nsis-casp-00.txt A Two-Level Architecture for Internet Signaling - chair - (10 min) http://www.ietf.org/internet-drafts/draft-braden-2level-signaling-01.txt Sender and Receiver Orientation Issues in NSIS - Robert Hancock - (10 min) http://www.ietf.org/internet-drafts/draft-hancock-nsis-sender-receiver-00.txt Analysis work - 50 minutes Analysis of Existing Quality of Service Signaling Protocols - Jukka Manner - (10 min) http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-00.txt Nsis Threats - H. Tschofenig - (10min) http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-00.txt RSVP Security Properties - H. Tschofenig - (10min) http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-00.txt Analysis of Existing QoS Solutions - G. Karagiannis - (10 min) http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-03.txt Analysis of Mobile IP and RSVP Interactions - Mike Thomas - (10 minutes) http://www.ietf.org/internet-drafts/draft-thomas-nsis-rsvp-analysis-00.txt Discusion - (15 min) Protocol Work - 20 minutes - If we have time A Proposal for RSVPv2 - G. Karagiannis - (5 min) http://www.ietf.org/internet-drafts/draft-westberg-proposal-for-rsvpv2-01.txt A Firewall/NAT Traversal Client for CASP - H. Tschofenig - (5 min) http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-casp-midcom-00.txt The Use of Bi-Directional RSVP in the Wireless Internet - Kamel Shaheen (5 min) http://www.ietf.org/internet-drafts/draft-Shaheen-shahrier-nsis-brsvp-00.txt Signaling Interworking for IPv6 Network - Gyu Myoung Lee - (5 min) http://www.ietf.org/internet-drafts/draft-choi-ipv6-signaling-interworking-00.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 14 17:46: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 RAA04678 for ; Thu, 14 Nov 2002 17:46:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEMmMX31511 for nsis-archive@odin.ietf.org; Thu, 14 Nov 2002 17:48: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 gAEMmKv31503; Thu, 14 Nov 2002 17:48: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 gAEMlJv31478 for ; Thu, 14 Nov 2002 17:47:19 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04567 for ; Thu, 14 Nov 2002 17:44:38 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gAEMlAL14472; Thu, 14 Nov 2002 14:47:10 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id WAA08625; Thu, 14 Nov 2002 22:47:10 GMT Date: Thu, 14 Nov 2002 22:47:10 GMT Message-Id: <200211142247.WAA08625@gra.isi.edu> To: braden@ISI.EDU, nsis@ietf.org, robert.hancock@roke.co.uk Subject: RE: [NSIS] General comments on draft-ietf-nsis-fw-01.txt X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> I think 1/2/3/4/7/9 are all probably quite reasonable (and are basically presentation related). *> I think the point you raise in 6 is interesting, which I and others agonised a lot about in this and previous non-framework documents. Eventually I gave up worrying because I couldn't see a practical impact. John, I suspect that if you sat down to design a real implementation, you would soon discover the practical consequences of the fundamental model. Which brings up an interesting point -- when the RSVP WG started, most (but not all!) of the research and simulation had already been done on the protocol, and it was only necessary to get the engineering details right in the WG. (Of course, the process of engineering and documenting led us to discover a few unsolved research problems, so there was a circular process.) Concurrent with the WG, we were building, testing, and demonstrating a prototype, and that work fed strongly back into the WG efforts. I worry that NSIS is too top-down; there is not enough "running code". ... *> The point in 8 is partly related. I have generally come from a perspective of thinking that an internal node could do arbitrary violence to the messages (do we even assume it is the same signalling application protocol either side?) "Arbitrary violence" -- OK ;-) (Either side of what? Either side of a node on the path? I thought the answer was "no", since your framework allows different NSLPs at different points along the path. You might seldom want to mix protocols, but it does not seem outrageous. In fact,the flexibility might allow you to divide a big, complex, multipurpose signaling application (NSLP) into smaller more special-purpose protocols and use each where appropriate.) (and quite possibly isn't what other people think). *> *> I think the most important point you raise is (5) - what message patterns we should support/assume. I'd really like to see some views about the range of options here. Important point: I think that the CSTP/NSLP layer should not make ANY assumption about message patterns, while a specific ULSP/NTLP must necessarily make an assumption, and different ULSPs/NTLPs may make different assumptions about message patterns. Right? Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 14 17:53: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 RAA05024 for ; Thu, 14 Nov 2002 17:53:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEMu6u31779 for nsis-archive@odin.ietf.org; Thu, 14 Nov 2002 17:56: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 gAEMu4v31766; Thu, 14 Nov 2002 17: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 gAEMtSv31740 for ; Thu, 14 Nov 2002 17:55:28 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04994 for ; Thu, 14 Nov 2002 17:52:46 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gAEMtKL20380; Thu, 14 Nov 2002 14:55:20 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id WAA08643; Thu, 14 Nov 2002 22:55:19 GMT Date: Thu, 14 Nov 2002 22:55:19 GMT Message-Id: <200211142255.WAA08643@gra.isi.edu> To: braden@ISI.EDU, sven.van_den_bosch@alcatel.be Subject: Re: [NSIS] General comments on draft-ietf-nsis-fw-01.txt Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> 8. The text tends to imply the model of a signaling message passing *> from NI to NR through NFs undisturbed, rather like IP packets *> passing through routers. (See for example the first sentence *> of section 5.1) In some cases this may be the wrong *> conceptual model. In RSVP, signaling is best thought of as *> hop/hop; each hop propogates state in each direction, to keep *> certain invariants true. Also, refresh messages are generated *> independently and asyncronously at each hop. It is true that *> hop/hop action is forced by support for multicast, with its *> merging, so it may not be directly relevant to NSIS. However, *> there may be other signaling applications that will best be *> implemented as hop/hop signaling. *> *> [Sven] Would it be improved if we were more stringent about the NTLP/NSLP *> separation throughout the document. More emphasis is placed on this in the Yes, I believe so. *> current version but maybe not enough throughout the text. I believe the *> framework should talk about both layers. I also think that the focus on the *> hop-by-hop aspect may be different for both layers (more for NTLP and less *> for NSLP that is). Assuming that NSLP is what contains the description of *> what actually needs to be reserved or done, it is reasonable to describe *> the interaction with RMF more from the NSLP viewpoint. *> Yes, I think I agree. *> 9. Sections 5.1 and 7.2 (which are somewhat redundant) seem foggy to me. *> For one thing, an RMF may be specific to one or more signaling *> applications, and there may be many distinct RMFs in a single *> node. *> *> [Sven] I agree. On the other hand, if an RMF is specific to a signalling *> application, the complete picture could be assembled from many of the *> current picture in parallel. *> *> Also, Figure 4 (which is repeated as Figure 7) and Figure 8 *> depict two quite different kinds to things [I would call them *> "entities", but you've used up that word ;-)], and it is not *> clear to me that you can usefully encompass both in a common *> abstraction. I see two kinds of things: an inner-RMF, which is *> the interface to the local node's *> *> [Sven] The idea was to clarify that there are indeed to different types of *> interactions with the RMF. On the one hand, the RMF may just be a server *> which assists in performing admission control for locally controlled *> resources (what you call the inner-RMF). On the other hand, it may trigger *> a new layer of (local) NSIS signalling. This is what you call the outer-RMF *> and what is depicted in figure 8. The picture may look a bit 'centralized' *> but it essentially expresses NSIS nesting where the RMF can be either *> client or server. We are having an agreement, although the text needs some work to say more clearly what you just said. There is an issue that is partly (but not entirely) just expository: are the "two different types" should be given the same name "RMF". I think I could argue that they are so different that it would be clearer to all if they had different names. *> *> I see "inner-RMFs" (Figs 4 & 7) that are local interfaces to *> the traffic control and admission control mechanisms of the *> forwarding plane. The WG should look into how an inner-RMF *> relates to the FORCES work of the IETF. *> *> Note that when an inner-RMF is a server, it may supply *> information to the NE as well as accept control state. *> Examples are admission control decisions and the Adspec *> machinery of RSVP v1. *> *> [Sven] I fully agree. *> *> Then there are "outer-RMFs" (Figure 8), which seem to have *> quite different characteristics. This section to be an attempt *> to bring the bandwidth broker under the NSIS umbrella, but *> this may/may not fall into our chartered area. *> *> [Sven] It does cover bandwidth brokers but it is certainly not restricted *> to that. There is no argument that bandwidth brokers are currently not the *> priority for the NSIS WG but it is also agreed that the framework *> should/may have a somewhat broader scope. I agree with that, and I think the material on Figure 8 is just fine and belongs here. *> *> Finally, it is far from obvious to me that the NF/RMF interface *> corresponds to an SLA. *> *> [Sven] I think it depends on where you see the admission control. If you *> see this as part of or colocated with the NF (i.e. handling of NSLP) then *> you can think of the RMF as providing an amount of capacity (e.g. the link *> bandwidth for a certain class of service) in which the NF does admission *> control. I agree that there is a problem here with modularity and interfaces. I wonder whether the FORCES work might give us some useful guidance here? Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 14 18:00: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 SAA07424 for ; Thu, 14 Nov 2002 18:00:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAEN2PZ32003 for nsis-archive@odin.ietf.org; Thu, 14 Nov 2002 18:02: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 gAEN2Nv31996; Thu, 14 Nov 2002 18:02:23 -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 gAEN1Uv31948 for ; Thu, 14 Nov 2002 18:01:30 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07321 for ; Thu, 14 Nov 2002 17:58:48 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gAEN1LL24244; Thu, 14 Nov 2002 15:01:21 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id XAA08652; Thu, 14 Nov 2002 23:01:21 GMT Date: Thu, 14 Nov 2002 23:01:21 GMT Message-Id: <200211142301.XAA08652@gra.isi.edu> To: braden@ISI.EDU, nsis@ietf.org, brunner@ccrle.nec.de Subject: Re: FW Bob's Point 5 (was Re: [NSIS] General comments on draft-ietf-nsis-fw-01.txt) X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> > *> > This shows up most directly in the terms NI and NR, whose *> > semantics are sometimes confusing. Of course, *I* prefer the *> > abstractions p-src and p-dest that I introduced in my 2level *> > document ;-), but perhaps NI and NR can be made to work. *> > However, that will require careful definition and usage. For *> > example, RSVP v1 depends upon signaling in both directions, *> > using both Path and Resv messages. So, for RSVP v1, both *> > sender and receiver act as both NI and NR. Some of the *> > discussion does not seem to encompass this generality. *> > *> *> Bob, *> *> I think we cover 80% of the relevant cases of reservation styles with a *> simple one-pass scheme. Concerning the NI/NR terms. I like the NI, because *> it does not say something about who is performing reservations, but it is *> driven by somebody initiating the whole thing. *> *> Marcus Marcus, I would suggest that a model that cannot describe the existing RSVP is not adequate. As I said, it is probably possible to define the NI/NR model with sufficient generality so it will cover two-ended protocols like RSVP. It is OK to use a simplified picture for explanatory purposes, but we need to be careful not to fall into believing that is all there is, and careful not to write words that explicitly exclude the more general cases. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 14 18: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 SAA08611 for ; Thu, 14 Nov 2002 18:43:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAENjgh02144 for nsis-archive@odin.ietf.org; Thu, 14 Nov 2002 18:45: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 gAENjdv02137; Thu, 14 Nov 2002 18:45: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 gAENiSv02102 for ; Thu, 14 Nov 2002 18:44:28 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08553 for ; Thu, 14 Nov 2002 18:41:46 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Nov 2002 23:44:20 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5E80@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Bob Braden , nsis@ietf.org Subject: RE: [NSIS] General comments on draft-ietf-nsis-fw-01.txt Date: Thu, 14 Nov 2002 23:44:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Bob, > -----Original Message----- > From: Bob Braden [mailto:braden@ISI.EDU] > Sent: 14 November 2002 23:47 > To: braden@ISI.EDU; nsis@ietf.org; Hancock, Robert > Subject: RE: [NSIS] General comments on draft-ietf-nsis-fw-01.txt > > > *> I think 1/2/3/4/7/9 are all probably quite reasonable > (and are basically presentation related). > > *> I think the point you raise in 6 is interesting, which I > and others agonised a lot about in this and previous > non-framework documents. Eventually I gave up worrying > because I couldn't see a practical impact. > > John, [reh] i'll answer anyway ;-) > > I suspect that if you sat down to design a real implementation, you > would soon discover the practical consequences of the fundamental > model. [reh] I'm assuming other implementors are happy to structure their work without being constrained by the model (I certainly used to be). What constraints on the protocol do you see? > > Which brings up an interesting point -- when the RSVP WG started, most > (but not all!) of the research and simulation had already been done on > the protocol, and it was only necessary to get the engineering details > right in the WG. (Of course, the process of engineering and > documenting > led us to discover a few unsolved research problems, so there was a > circular process.) Concurrent with the WG, we were building, testing, > and demonstrating a prototype, and that work fed strongly > back into the > WG efforts. I worry that NSIS is too top-down; there is not enough > "running code". [reh] I half agree, but this is the way we are encouraged to work these days. I am sure if someone turned up in the WG at this stage saying 'here's my implementation' someone would protest anyway. > > ... > > *> The point in 8 is partly related. I have generally come from a > perspective of thinking that an internal node could do arbitrary > violence to the messages (do we even assume it is the same > signalling > application protocol either side?) > > "Arbitrary violence" -- OK ;-) > > (Either side of what? Either side of a node on the path? I > thought the > answer was "no", since your framework allows different NSLPs at > different points along the path. You might seldom want to mix > protocols, but it does not seem outrageous. In fact,the flexibility > might allow you to divide a big, complex, multipurpose signaling > application (NSLP) into smaller more special-purpose protocols and use > each where appropriate.) [reh] Precisely, and [personally] I can see significant advantages in being able to do this e.g. in the QoS signalling case. More generally, at some stage we could consider the question of whether we expect there to be lots of simply NSLPs or a few complicated ones. > > (and quite possibly isn't what other people think). > *> > *> I think the most important point you raise is (5) - what > message patterns we should support/assume. I'd really like to > see some views about the range of options here. > > Important point: I think that the CSTP/NSLP layer should not make ANY > assumption about message patterns, while a specific ULSP/NTLP must > necessarily make an assumption, and different ULSPs/NTLPs may make > different assumptions about message patterns. > > Right? [reh] Agreed, modulo changing NSLP<-->NTLP in the previous paragraph. (Although this is probably not the current framework working assumption and needs discussion - I think our starting point was more "There's a set of basic NTLP messages, whose payloads are specialised for different purposes." I could - just - see that working for QoS but not for everything else now on the table.) The only exception I can see might be that a very lightweight NSLP could elect to use the NTLP in a purely forwards-along-the-data-path mode, to really minimise network state storage requirements. Is this a useful optimisation? > > Bob > robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 15 02:43: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 CAA01916 for ; Fri, 15 Nov 2002 02:43:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAF7jQp05040 for nsis-archive@odin.ietf.org; Fri, 15 Nov 2002 02:45: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 gAF7jOv05024; Fri, 15 Nov 2002 02:45: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 gAF7iUv04970 for ; Fri, 15 Nov 2002 02:44:30 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01884 for ; Fri, 15 Nov 2002 02:41:43 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gAF7aF204743; Fri, 15 Nov 2002 08:36:15 +0100 Subject: Re: [NSIS] General comments on draft-ietf-nsis-fw-01.txt To: Bob Braden Cc: braden@ISI.EDU, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 15 Nov 2002 08:44:01 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/15/2002 08:44:03 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Bob, Thanks for your comments. I think we can summarize the outcome as: - clarify NTLP/NSLP in the context of RMF (according to the discussion below) - clarify the different types of RMF interactions, probably requiring different names for both types - link to FORCES CU in Atlanta, Sven. Bob Braden on 14/11/2002 23:55:19 To: braden@ISI.EDU, Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: nsis@ietf.org Subject: Re: [NSIS] General comments on draft-ietf-nsis-fw-01.txt *> *> 8. The text tends to imply the model of a signaling message passing *> from NI to NR through NFs undisturbed, rather like IP packets *> passing through routers. (See for example the first sentence *> of section 5.1) In some cases this may be the wrong *> conceptual model. In RSVP, signaling is best thought of as *> hop/hop; each hop propogates state in each direction, to keep *> certain invariants true. Also, refresh messages are generated *> independently and asyncronously at each hop. It is true that *> hop/hop action is forced by support for multicast, with its *> merging, so it may not be directly relevant to NSIS. However, *> there may be other signaling applications that will best be *> implemented as hop/hop signaling. *> *> [Sven] Would it be improved if we were more stringent about the NTLP/NSLP *> separation throughout the document. More emphasis is placed on this in the Yes, I believe so. *> current version but maybe not enough throughout the text. I believe the *> framework should talk about both layers. I also think that the focus on the *> hop-by-hop aspect may be different for both layers (more for NTLP and less *> for NSLP that is). Assuming that NSLP is what contains the description of *> what actually needs to be reserved or done, it is reasonable to describe *> the interaction with RMF more from the NSLP viewpoint. *> Yes, I think I agree. *> 9. Sections 5.1 and 7.2 (which are somewhat redundant) seem foggy to me. *> For one thing, an RMF may be specific to one or more signaling *> applications, and there may be many distinct RMFs in a single *> node. *> *> [Sven] I agree. On the other hand, if an RMF is specific to a signalling *> application, the complete picture could be assembled from many of the *> current picture in parallel. *> *> Also, Figure 4 (which is repeated as Figure 7) and Figure 8 *> depict two quite different kinds to things [I would call them *> "entities", but you've used up that word ;-)], and it is not *> clear to me that you can usefully encompass both in a common *> abstraction. I see two kinds of things: an inner-RMF, which is *> the interface to the local node's *> *> [Sven] The idea was to clarify that there are indeed to different types of *> interactions with the RMF. On the one hand, the RMF may just be a server *> which assists in performing admission control for locally controlled *> resources (what you call the inner-RMF). On the other hand, it may trigger *> a new layer of (local) NSIS signalling. This is what you call the outer-RMF *> and what is depicted in figure 8. The picture may look a bit 'centralized' *> but it essentially expresses NSIS nesting where the RMF can be either *> client or server. We are having an agreement, although the text needs some work to say more clearly what you just said. There is an issue that is partly (but not entirely) just expository: are the "two different types" should be given the same name "RMF". I think I could argue that they are so different that it would be clearer to all if they had different names. *> *> I see "inner-RMFs" (Figs 4 & 7) that are local interfaces to *> the traffic control and admission control mechanisms of the *> forwarding plane. The WG should look into how an inner-RMF *> relates to the FORCES work of the IETF. *> *> Note that when an inner-RMF is a server, it may supply *> information to the NE as well as accept control state. *> Examples are admission control decisions and the Adspec *> machinery of RSVP v1. *> *> [Sven] I fully agree. *> *> Then there are "outer-RMFs" (Figure 8), which seem to have *> quite different characteristics. This section to be an attempt *> to bring the bandwidth broker under the NSIS umbrella, but *> this may/may not fall into our chartered area. *> *> [Sven] It does cover bandwidth brokers but it is certainly not restricted *> to that. There is no argument that bandwidth brokers are currently not the *> priority for the NSIS WG but it is also agreed that the framework *> should/may have a somewhat broader scope. I agree with that, and I think the material on Figure 8 is just fine and belongs here. *> *> Finally, it is far from obvious to me that the NF/RMF interface *> corresponds to an SLA. *> *> [Sven] I think it depends on where you see the admission control. If you *> see this as part of or colocated with the NF (i.e. handling of NSLP) then *> you can think of the RMF as providing an amount of capacity (e.g. the link *> bandwidth for a certain class of service) in which the NF does admission *> control. I agree that there is a problem here with modularity and interfaces. I wonder whether the FORCES work might give us some useful guidance here? Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 15 05:29: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 FAA04335 for ; Fri, 15 Nov 2002 05:29:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFAVcx14224 for nsis-archive@odin.ietf.org; Fri, 15 Nov 2002 05:31: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 gAFAVWv14216; Fri, 15 Nov 2002 05: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 gAFAUFv14173 for ; Fri, 15 Nov 2002 05:30:15 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04316 for ; Fri, 15 Nov 2002 05:27:38 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAFAUCQ1013335; Fri, 15 Nov 2002 11:30:12 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WWL2MPMM; Fri, 15 Nov 2002 11:30:12 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Nov 2002 11:30:11 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE1C7@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: c3662351 ca231590 e0b3691a 00000138 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" Cc: nsis@ietf.org Subject: RE: [NSIS] Updated agenda Date: Fri, 15 Nov 2002 11:30:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C28C91.F414DDF0" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling 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_000_01C28C91.F414DDF0 Content-Type: text/plain; charset="iso-8859-1" Hi John Thank you for updating the agenda! However, I have a comment. As you already know in the presentation of: "A Proposal for RSVPv2" I would like to only present the used concept (see slides in the attachment). The used concept is an enhancement of the concept introduced in draft-braden-2level-signaling-01.txt and therefore, I would very much appreciate if I will be able to present it! Could you move this presentation to the Framework Discussion slot? Best regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: donderdag 14 november 2002 23:24 To: nsis@ietf.org Subject: [NSIS] Updated agenda Tuesday November 19, 2002 1300-1400 Afternoon Session I WG Status, charter discussion - chair 20 min Terminology Discustion - Robert Hancock Requirements - Marcus Brunner - 20 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-05.txt Wrap-up - 10 minutes WEDNESDAY, November 20, 2002 0900-1130 Morning Sessions Framework Discussion - 50 minutes Next Steps in Signaling: Framework - Robert Handcock - (15 min) http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-00.txt Trade-offs and open issues with path discovery and transport - Henning Schulzrinne - (15 min) http://www.ietf.org/internet-drafts/draft-schulzrinne-nsis-casp-00.txt A Two-Level Architecture for Internet Signaling - chair - (10 min) http://www.ietf.org/internet-drafts/draft-braden-2level-signaling-01.txt Sender and Receiver Orientation Issues in NSIS - Robert Hancock - (10 min) http://www.ietf.org/internet-drafts/draft-hancock-nsis-sender-receiver-00.txt Analysis work - 50 minutes Analysis of Existing Quality of Service Signaling Protocols - Jukka Manner - (10 min) http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-00.txt Nsis Threats - H. Tschofenig - (10min) http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-00.txt RSVP Security Properties - H. Tschofenig - (10min) http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-00.txt Analysis of Existing QoS Solutions - G. Karagiannis - (10 min) http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-03.txt Analysis of Mobile IP and RSVP Interactions - Mike Thomas - (10 minutes) http://www.ietf.org/internet-drafts/draft-thomas-nsis-rsvp-analysis-00.txt Discusion - (15 min) Protocol Work - 20 minutes - If we have time A Proposal for RSVPv2 - G. Karagiannis - (5 min) http://www.ietf.org/internet-drafts/draft-westberg-proposal-for-rsvpv2-01.txt A Firewall/NAT Traversal Client for CASP - H. Tschofenig - (5 min) http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-casp-midcom-00.txt The Use of Bi-Directional RSVP in the Wireless Internet - Kamel Shaheen (5 min) http://www.ietf.org/internet-drafts/draft-Shaheen-shahrier-nsis-brsvp-00.txt Signaling Interworking for IPv6 Network - Gyu Myoung Lee - (5 min) http://www.ietf.org/internet-drafts/draft-choi-ipv6-signaling-interworking-00.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_000_01C28C91.F414DDF0 Content-Type: application/octet-stream; name="IETF55-RSVPv2-karagiannis-01.ZIP" Content-Disposition: attachment; filename="IETF55-RSVPv2-karagiannis-01.ZIP" Content-Transfer-Encoding: base64 UEsDBBQAAAAIAMJ6bC0qkSSFPzoAAADoAAAgAAAASUVURjU1LVJTVlB2Mi1rYXJhZ2lhbm5pcy0w MS5wcHTsWglYU0fXnpubmLCEREFURLm4fe6iVEVKBdytKCi4/rYQQtDUkNAkuC+oiGstVqu1KnVt lc8VP1t3qVq3QkGsFbfqJ5ZWazVqW61b/jlz700uIVHQ1v/5n4fxyZ39zFneOXNmsKiw5tU1O/z+ ixxSV0SjZ1Y3VEPQRuFfHF9RIhTPtT2zWq3Q9C7+WavT/6uUEFjfModGKLKVbGvIannhzUddrLGr N4+T1bPbPV+B0DkZQp+4vYuUq95AQ2gw+viVl5dfGXMmxue44VPdr+ZhqbFK1b6H2wMS/uUVv7L7 JcUxny0b6j9q1O0XfdPijo1PDqk7xf/auocKz8njHt5aEX3wVv+SH2dPy5s8+Pz+n5toiy+tf6Ne 6y1f/OfBisWmC5O6Hggvjms0M+PEvu4Zvy9qIOp0+LPSp106vP3d7hbjnwzq/MO2rFEjzhf1P5A4 MOR26bNv651AHZd0OdXweuaeRzMP+i72/aNNd3WNNttDw+MeBrc7n9LroxMd8x9NTpZOy7o6eEKP rVu19fMz/EcUd/5+RHDs4Wj/o4XvX1GnfzVtz+xxe+otm37hhOH2b19dCTV926Wx+kn/n3r/Oen2 71G+194xldbWRY/Pzr84MP/g1sknDxZ+sGhWckDmkV931x9yYEHHBUnHVj3RZhvuji2rNX7p6d4n Im8379ci5fppv+weDTTP6nZOyzQXHtm6LET85MraixdGjZV02heoa75CtX/5t+HmJr80v3889QPp O/llR5/82WJlwY68smFJ6g7q/2kVvPns2d+O9e8z+ULYR9uXL5uhy2u8oP6+MqtxQM+d571Lbu0a 1f2tBiePndu7SXu/z+GyuATThbu7b/R5ELRiaL0PC7xyqcLFozt9s6F41bW3Tw4ftee9rXuyx6on b7ofPXS+NriL4ottXQekXRdnf7ywbKjn5dXbzjT7aEmRvEsfWViKrOlKzeWOhdeUOR4ZNxutOdFv ZcjSTovWZ3hJus3+7XhMwhfuO4uG/7BT/Ut2rSbibGbNJ8H9vpc/apTSqK/blLgZb/qNz2iw5dSX w8/+uCemeOGuxnWGnps4sffjDeJt8/Iaj6wdudyLXrJqTO/PCxq7rfh5SmSnq2657bfcODVk13/7 3rzZMrggqED95O5bJ5PjE3YGHC570ioGFFDv5oOS77Pk431HnE9tFabXR8/S+PWu87Z255wjpVs+ nD0vLM8Uf/X0f/p++Syz//lB/x6eX2RW5wx+s/07w9NCZs2lPjzcehAqHNZKMrLNKk3Gd3tn53yz u3TGwS3jDk7tmjd1xuzMB95Ldy2dOqN07bGz0fHR9f70CTNteWvWlXWLeyYX1Z6yeGndSw8Htem/ rX/BPa9fawTfaBaurffehrUfa/fk3Jux/aP5AcPv5sSfmHjWkPjH1eG6LQ1vp4c+eKSPfTbzUq8d 6w0bR7T5tNeGnHMpshbt5xQevTKgj6Uw82m7jAVvPKO6BUTnoupUnapTdapO1ak6VafqVJ2qU3X6 h5IC/UK7K+Ed5wbdHNfTfRG6qmR/UJbgNnf8k3LjKfZDKZCbmL2suIvF+FuD0MpXZJO2AoXMPj6I QkcUdfm5grwOfHITkRLtVXjhYgzSIjUyozRkRBrE4FZ/3DoUGXA9CbV16G+LQlAQHtMaj+lPeox4 pAn/kvEYxjaPcZinQPfoMMxCO3RC4YnnBqFihZjjSIHOSj8hpa8UPRC8dmlRCp5jwlQG4Hwczgdh uilIhfS43//LRPJrjqV4eIYOisI5SA751O/pIITEWDqWViReXYvn6XD55WjVaITQJgVvDRFqgNmO QOsUMFuCrE/Dcd6IQVhmNvE5HiVCZAa8z90hLezrD1iFmAObmaEY1jASGM/OgHICnUDz5XRxOlGV AnmIn1CQI8vvZFYNCzYzEmch1BTXWiIWNRQZy67MIDbxL4q8zvm6SJDDgnKHflfzJFwu4/oglzoZ x6NUIqgL24V1V7mM+1V2PM3lbg7tHlzeDlGWYQhkllqaIGfJ6lCfiDpwY2mx45udFWXR9t0FY9XI g4ydTuHVZDOhS3aIUmJM5lG4IrNSMiwPJcI6l0Ugv7tKRJCBombsRfn5+YRKBGpI2qUwHicY+wAh ZQCyKELIiPu0D2LtxsuIUzoS9EkEfRTXp0BF0qO4EoCs/Hyxp30+oadAj+hRpPaMprnJ6Cn9Bv52 QizA+XwYt01iuG2TXAuhPKz3a0+s1lzMNsxMRY9p3jGlyux16IvwAFak4jDSy64RyNHmc13WWNIL 29SuZkGirNYA1yx35sjwuSPLfMp5aLVudsIysChkGUQIQLJyLHfjaPP5C1lGwPIc71AE2p7n3YG0 sf44nvyLwf/iUBdcn+8NdnLmN8PReQVruwtcmyeKrtD2Fl7BokiFzcDhgt8fZO/b2PuMjGf37UZF A/yN1DMDDbFMZFRsDNN8MP62YFKNhlSDSaXzYBBao2iGBzXk56P65CvCLod3KhTXAg4vR4GnkKWh 101MczUal+vaWpUcG6y7yCGiUNxI6OdFqM2tALPkDiKwaaMCn6No6OgJjHm01oQZ15g0erPKrDXo w4EyUPFF/LoUX5LxHFAclQX4G8NOZlSM2qBXa1LNmKbKzGj1al1aksbEqJKStEDYxJgNuEtjG6bV m42GpDS1JgkXmSSjKtncJtGoStLo23TQacZqdG1M2lF6la6Nyqge3SaofVvzeDMj76nTqrVmJlmj SUpUqccwyUZDCiE7tHegHHiPQHD48ryDyXhN1kHO9BvgRE5ek+6cvqBV5EKTgJ3urEihDDDgzk0s bzReZTNwIVaTqjISbYPk5nEGJkWFCxg/ZoPaoGOI9KbWjNmo0ptSDUYz07x7bBxGmEqfxKhSU7EK 2NnNCfwMRoYAUC6Ps00gJELlJm2KVqcy8qoHKkyaqSoalxPWUgxJ2mRu1VBGjkkwhmSWnAnjRpOc ptMxegO2dyjbqhqnMmpICwsHoGLGP4wHwbSKhHQak+m5hJIMGhhgp1iOIJOYhoGFF0nUaUBorFI1 UCR60uqTDcYUIgNsUPBHw4lVWNvUtBl1qK3tMOKjgPcEfXwPm3IUUfi7AFUecoG2VndB62ZbKw8/ /g9e0Kr8e+B3+J+EX6SgzzkAyYSqAZCY1JSmNfM2xWbXGFVqMzNOax7tiEFg0RmaWjPY9oxmvCol VacJlbOM650OZdQqPW4zGPE4luFUjRGUkYx3AKPWqfBAMsXkhIx9IwjJ2Kgk6wzj+MmJBsy+sx4i xHMXBviOR+Xh620DxTJbW3PEwxe8HO3QNtDWphPM5Mfws4T1gYhPOYpE/F2IKg/6xsgZ6Cc5bVXb WvmtACE7fyxLXWwFCM8jMXC0Zo3anIa9Br8dvGzkym8H10eoL0cUZnm5WA4o99Ca1GkmE/Eo7LFp 33quj82l+NvXRDYEd/TiDcEfiyo1ZDzY2ZNN3t2QpktiD2t+XKKG7IRReCfj2bAXYDMLzlc76Urv tXAAVhNkBwLCd1o2RcIHgm4lDwaQGELdNF7OSoBAZGtth+Muf0KF1bgw2rTHXTeJYRToIf2uFGbe oflbOyWSupWbg1MCskgZxN4XIMF9IT4+Hh0v6oIe9MXrDt9N7hH8uLLrFyo1bvfpskqNS09PJ2vD OMj5cTCfXWudoivwXoWbMQWjSSLaosEI6xQTEX+/phyogC5LKlBBNir8/TodR5HezPfkhi3Cs6De iCkSsfPYXgudQENvLVLfh5QS9q7NPPeGzwe9jhzwN3xPjoOq3vBj8KpxbBOi3HgiLPeUrYWlJ7LV WZq0rc7SFdvqLO0ETNuLpyjjKady9uLv5/xafLkWEgnKtK2stN0soZzuhEotARWlgIpSQMVLQMUL 7wFPcV0x7AWRRSkGFMgs/LuCF6nXvcv7GAWiLStpyMWW5qTNzQJb1/vK8cHvt906Z+f7ft8dDey6 UITcCQ1YSILY8YNwXotrB38IDs2E7+zwfjKLcDqbrFH+zo5sd/Y5NCuZ0sLvznTflRRQHiag7M5R nokpBzlQnk7Bnqoc/dGAZN8jhH6UgL6Mo8+/NlSGc57mVgXQvKoEmsUCmiKO5jpME+6308jeTEdN mLFoOuHpEF5F5PCyQeG4kl8L28FhrRuUBWXVDqIVqCaxEEJHPHi9UWgstojcMoDUyp89fvjbHcda Y+CM0OALFtNfZcJhEY4PJug0CK1VgC+uz41nT8H6iMc1SNaIsktGu5As4xUky6NBsiiZo2QwWcRJ xr7Mlj8bB7mSzKzBsSARzySP1eBDLomNMeVxo7VGvtzLkGbEURVX0SbzZdAI+KVAsoqcrOdJOIEy TcrABaupWCTUlHBHeDxnR0ynwO+/CF05BF3nFEC5j4AyqBbY4HfEdKLlmRTel7LF1MLP5qMl1I8H RmP6tfAclrKYBicWToO1lJU80+ANuxbujyJvvElYEjUupZJX6Nv0cLH9lAXJaLHtlE1HXAJP5MZ5 IuA6SOCJPBnW+yx34n1msALaks37MHbvI9zDItz+snsYEu93hPYTczSd2+95fudFHkfyCtwKPY6Q W9lzua0q2pBgx3twlEsxZThTbb6sMez41hoKW2tZLqARyhmkzMmC1wuokidYLfk3ddhnVgVPAInm PMEQUiv/ygYsOvcEWjMOjst5ukCOHhvRByJbRC/zRo3uwohD0CAGPTxFdj0AXkEPZ7AewM/yerj+ HD1UXQMb3AbTdbyL5c58oZjTAHuVEz7wbVTAlcm5l09LdKKEJqwOOCVAzbUSyrkeBlXS9TSEp/GX dj0KZKEtEhD7Lv+AnI4XDgKHsl3COpSNEAgKHIo0jHUoEZKKDsUx2RxKmN2hnEUChwJnmyDoAGNL MAtJTcdWyZyQYqQM5QzQ7iLWnO+QGmtO9uDeqADiLeGGxf9tgk0i7gtG+0twyufY/kLJm1FYBuHO IcEZ7kK4o1UWLsvtqrKicDBZirKIcPGk3YVw/LsxIkRF5cR7WCXxkpDAcXPi8e51Gl5YzLmkaRTQ OUTVxILBn4/cULiIIj2sSNupIpHSi3F3FAk4kxCRxJa6AucocaHKJs2qpsrt7hGi1V5FPo7rgow1 RKwqV5N2VpWspv7vQyAoxaLytriI7PqpwelnMdYPPADw+snA+plNpKiKlhJqw25K93XUEvDixmnp JXfToyrB7TKyiyh1IeL1lxQR9lRFEcFJyUSvuKdKqiRkOb8PQrr0++DxlxDv/6KQk39ugecPkvKX o+DgfHwOWFFubi4JLM+L7IElJAXnwCk4AyjW18M5MFfEngPTRRAXsucA8B8gY8+BeqKK50DwvKbJ Te4XyPTLJu0+7fmTn+0ckNnPAXjh5OX2wx8G0+mO5QZ+0lGPJmOxlEDRSr4UTQIkznypIghgEmo4 8/cK7vhmA9tsmy1gzRSBT2kIn3JXLEQAJW76vCsWEsAKVYBVkSRVFOP9gxT4ak3W9FGCb8TnK/e0 htXaA9kS2IwmjMqDgOcC0loeck3xt7fGYBylNZja9lMZVaO0Kr1ea4rQ6PRtNUat2mQy6NuaNHKA JfxltqmAPPwWM/D1xl8fWx/0IHgHFFPkfSqHuDgZ4qFKceM8KrTQFVrss3hVQw02hFvFwAY+f8Od 6kXvegBwpQDgsIzcC/EpHT48wPMoFuC7KXjRsgOczmABHkNVIdDJsAPciASBTgYL8FgsN7h8AJsY HHR0lgPMyZtGJd4i5NzJ7wzm2YKVaRcriwc6rkwLVmbfCm4TIIchF0C2ezkCZBEHZGF84uWES4rj shwuMJev464NuHCvJC72crjIpeA10o4LcRSLi7ergosoF7iIcm6d9TH/BC4+Eaws5la2u9yMQS9G RIlnVRAheRVEwFX+NSHCt5KIOMYh4iDOtws9RRaLiCFOEeGO1eKO4MzI3zHRjogsOyLgD4c2RGSx drGH1Swiegxxhog53ON0ZXDxR+X8RVZ5ROL7ylBnuCi/MouOLK9XR0dFLp2iA3P5ei7It2n/SqIj n0MH/H+1dAE6pDoWHSOr4i90LtChc46O9bGvig7XXmM9znPFXBSO11cKgiZxJJzzHgBuFE5WdgyX nL2FhYvY+IDlK0SMT+rahQQ77P8V/NrDbvcXB1CULYBywAhEmK8JIy8Ta2QJPcicl4g15rg4U+Yg p2fK9Qr+/W+PNVys3GTwi0+WCzWq4jv4oPmlThbM5es5WSz0TSIv97hGgSDs41oOh4O1OE8V4iCC xUFoVXAQYceB8C96oghU7oRnH2jgZgx2IDuHZv9b6PMfZSB5cI8yawX06Qjn1u5BYhfhKhLhKi6e YMAInpwF2f+rKnyCYd8UKMQnivtCXuH/jFS8Vkeg13KtVqKaytFwZcKeZ/zK30aO0fmcq901+M0x d/zqt/Parfwiefzy3nk7CtZlDkrMP/b1wMR9ZYs29l3cNtl/6eYDt2/XqvNe3FBjq6x7RzZ8/GnA ImXIX4O7ab/9MCfHZ8anKGXt51rvuE2Kefd2hi+VNe0feyvbdGfV5bv53+UqZn9z8unm0kll301Z Zbh96fj55RN+/vD+1lWPvjlgFdX/crq02RdPYpLnxmYEiVHc+2FdOnbU9Irum9/yUrdNPueyjs4P fee+0SdgXsAGkWZhn53+R/Y0P7vfIy9sid+SSTFl61pHbOr5V61T3Zb0bBTfIPPBmsn1NjTUtJ+3 MFesaXGqQ7/6fjHxc3PdNR1P+S15PPCHeW98ULdrenFG8YLiGbkNNTND2i16c2LgvGlu+30VXzOZ 7UN0Ae65a333b5r07rqppUOHP5FM3Xvk07G/D1GnXnvY8xu1V7PWv2TK6k44q+0p2TjvbPbI+wV1 VMG3MpW3Wu2Wm3ZM7TBLd2rX1GtzL4dF/Hkn4pk0QTahRCq9v/XQ5+jxpgPSjAEP5rvfmBR9bb5k VnSppPvX2aWbrk65MvXOGX/LsN3tfD/o/dj7UenpkqkH/nVpWYhPcMmSeyVt57n3elyS1G3iupDL Je6dO1vvXdyzKy826v4hy8bIe60sLbvOXXO+ZupCw77p60QFf2iKZpXGevbeqFy4aP/O0UHbz2zr 8u0F94sXu64MnRVY4BHpP/Bx+3OB+b3v91PcbL9k1HlroP9088qGa3U/7CiVj8wceXfEkBWbp20a MaJQJ/9p363a0unmli3/l70rgYdye/+vfYkQkqWh5TKGIlv9rFeKpK4tok2DwRSDGUuEKST7Ukiy RJZwM9ZrKUsol0giIlmytEnJVtb/vPMaV0W3+7vV/3e7cz4fzjtnzpztfZ7znuc85/t971TzIIRc lazk2ZpEabMixTxKmaXGsAkm4yMGHE4PzcW0DkUmGQS/6K2LEjPFqVt5TfJTGYpk8KpraPSY8U2F DfZ1XQ3q1prcoS5F4FOs2fAr9aYif+4+bT0qTfdQg4KsocDxNOZoZm5xQdlasfsFZieKz1VLpyOs jOVENH0C/dXpzj1/KRfyvE7m6qrh3elJfLpe20XsbhWs0Eo88+g4c/4kW+B/njQwRJ9d7cfmymVI I/FgY6RV8m86m+bUnsyVUl/AFqr3XXBLZ1VvunB01E9nspxa9qiodfgx617cs8r8Xhm3NBSMMGCg FO2+UVLrEStysIy+KrvaEbktEClxyVHt5zxMFXbfG1duA1EJ/ZL+9QfL9biGz3IJ3FackhR5zPSS 3+gVrlYmovvAlNPga6T9hGJhWL/oxDuDBxnHMl2s9tr59ku/KWs7dkD0+L3Bk1TXOxQemq3M6gtL jTvumyiZnhLkM+1p1c0EDzaStvATUA4oF0Px1DZUugzCxvZKm8izMivYOe43CyBU5MuPBSkPNtrL eb7IYpB9IdZ2V3MXOZzw7srm3O8/U3ikjqcPn+SIsJF6PNE/Ln+Gjevm8a12JdGnYAMBwX0G+E3w gjF8tIeldF6c/pm5IobW6jw1a1N8kdm6dm1+u3bE02N47t1T6zNV7t4Qm1rnixQcem8VH12z4YnP yUbPR22v67wUNLPTLisOjOlUZT9nmLRUKFftyJpavUWD9khh9m7sVgGkZY1Xp44h65h4yO3gGr+t rQMjG5wGstZrZuwjTHamp5gEKDtOro1Y26iWncXRdD0Q2ZjiyMxWc6f0VL+rwcNtdzOvtNDLXq+k UY95+6yk8fS9o4jUimN9v2jmsgz46lyMTXNATEW8LENElTmla93iZdMySZ1pc05zXeWSk7oVmdJq FFXlVoVWunM4I3ZkbcYRlldpch3n24IH9rScjGIdeUAfVsYxov/aKu1y1Ep7wRID9wepLyd/l/cJ y6t12GrUFGV8sHvofe+459FyV+760HhenJ105Gn+x1ZbJB8WYy7paDp7ybK+GOzePCDMi59xsMBk KhQWDfUJY6ri2CZ46wz1G1pspZIkZAXP2OUezsapbQn2qLSZPdSpP9QR42CHk1LY6nrAuf/2qmhj rXqNdR175Asv1hV19SU1mGLi9Jo6BJAdOnUbhjpGaU8KPmtrE7tt3KxnhjmwtckoB4N32K+d9h9R n9QuoxN8Foq6dXdjhgiKoxwzz/Wk9eBqAYpOPnDhFWp0nSjnVvdINrXKlT4+sSxFm+3fqqbxioYn TKxlKYkvYWuzSN/z+4kL9e3Keaq50ju2OPm8vZEbM+lbWtAcyFV7j6le+YpuoJl6wJoGfg5l3BaD BmOeF8GHr1uOBTqp5RL84bezEeul6Rj21B/mOZb2Hu59CUOI5ffPxnFqy4wL+gcmGTxu3qCuGKdZ LdMymnvuUu5KzF2L7pR3HFeb3bgq9qKMoy+p3ma9laf9lL7xwcXouGL5UbfRzE49XBibIMMmN+81 gly5bTc1mDMCZxr4Mor4YHvWZNvJ/OZavPl+R4ShpQUS5RJ9ZlMgnb+xYiyd3AF/5I4uU5jPKnr1 joSMMTUthbLads0trgNO97PkrsVy2adOPmCIjOT7NZkr19FVC61SnF7t+1zhiporQTWYoLNeYO2h Ejp+gSBee3dGbWHThNlZu/hOHqYE1bpzCl25b3NLH1/4zcPXWHuLQspBbZhOz8uDGb0+MfocgSu9 K7yGrEc1EitjvFfZh6qItNglV3Qdu2yyTjmerXZmKqIVqZSV6nL8SK/udJFGkMp7eZ7xtR3OWScT T1ZcbCU8yOkKaznc82Rc6P2lJ23taWkv9sVcwjy5NDjHZO9QkcKZaclYXyDPKFv7Ss11JO2It8U0 oTEwRLJjY7AtD8zgsZpemUgwjumC2YnVCu17xadkcsZlYNpXp68hFPZcDym+N5tU2/Ur9niX96uH dwloQaPg/fCiNpvIpmOiT4uTY6xfCQ89Z5Xe25NQcnj8jdMr4GBxFw1e+pU8F0OuYlOcbKJg0JD7 9enR4QD/krKi/Iy8NwZFhMzHoWjHen/RWRE5hAW9R9CTaz2pAXKIw4FxLYcDsr0tWsSv1VTroiVS GBtcVle+xW1uCEV3bGvNPMdm8SyaqXhEpjot5NlJlwCLKpWqAET7mQp/0c5HkmosBva1AW2Vhm2Z VkOPShG10TaEpIOc5h1JOp6eE/ThRQ+THbkTmjn9qga9b5sMJ17I6xwdkZ3DCxm/MNSsY0+/Ljhc 3qq78t1Ru1STjLdZznUT78KpJsPOKmWpt5ZyogT6EbuVhhRZwqXhglfyIqgENFx4kjMFjqrUNugq b38fzXaUpX+Vv6e7xk5jn1U73ivX8nt0Eja/f//ofHMZxpgfzqbc5CV+2b3G3Xly8ropVqraQquO a9/OtKaEBI3Tt55udngO17pbcqB0tCP6pzu353qMlT0sev1xyZgrVZYrJAZNtWPZsgpG2FI7abpt p0WE6jrXOVYjBneOhks/bi9Sxpd6ztLVTb7SLn3aGtdCHYc3sUzDC4fazkgHmb6IrxI4sNNHY1g3 c6a772y8gyDj9KCGciG+nzC7+/VON42eLrfEkd5ypRgJ6ongMpZpJhs+md/7T/K+4xzDU81SnTpe 3nW+kOlG2T7E9HmWFdyzQWmsFV4tKW+cN8K4YeUiXLMlabai0zmNJ1+PssyEvjtRw8A3l8LlnHdr rXzEsI54B0+IBsOYUmFshXL4bq9hp9hSxwfcQaze64OmrjBJ5kSojhUADRo2Oe6vk/Kz/UqpT58o GPkPc5SHuMtg83AAc1NZdv+A6PDejSMZHKHrwkMXBzg9Zgo/rlox0enxOvl2cXkI3n9qLj8+htU0 pnW1xkmnyXzf8VcDzig04ZcGjnPEW1TI1k3X7eEVD8zJjWqVT7T1SV9WmuHtnno6Ul4mOHOwW/lU l1/OHG3TxGSfiuREb19j9lD8q6lnA3TKhjy+8tJnxqjuTNSL3aquf7mz1/ksJ8cGA4faLtV7O/uE G0ttnkQ5vEUrNjXxug30KMXe3PeywOzhmbeH3zE7HC0de1fAIfcz54HGm8FyCS2BeNWUfNNi4YeB fO4XTTmnuvyr+RPo9PMSBeqx7j9tXBwY5xgi+wflAADLs4e09pckLcdXEQ2KxnWgNcQOnOABrS0h oI0fAOQkwF04dqBWGLSS2IFJBAjJkgRyiGYmbBMAwLeAyA52oAM0t4AxyOokWgFe3JBJEaUI2Re8 ANmi/HfhofOoQZcbuJcDtQM0oMGBCSW1HwCuApC76gYA9akKgPpeB0DeoWYAIKFbOwBoXPrm+zEI QB6mUQAqexqAQBPgQX3QwcpCBbnFuaigc2rPqCB7sI8WAvKBdWtjNuHMsCgURkjfytYZSgfr2jnv GQOI6WBbo8qgNoP3kGa+nX/4sqCwON7CzUhqGxiWi2Hs0DXY9n1oGxRO6BeUs5CerQ0SQypfFYtG WpNGQt/FxtTWmtT5PUiMOc4MaYciDcFetBnWFmdr4SC03xZrLqSDJuEkSL34DJ5RSIj042XggmAt fwCQPvy0EvgYkQF2YBFogoUdumew+X6q22IcPoNcX/+/hDYHwQwg2nya9Cv6N9tAeYkBABD4CZ7W I+8zkKErQgAU6Odj8iYT+TP1ohjU6f8GbU4zHzMukY/8mZyf9r+IQVlnXPT5z2K6+Zj6o3Ry+8go 9MWo87/EZbDq63EZ/AOkKwqSLuJDZMFX/v/BZbCcdNEDS0sX/Uefl4vJ0vWl+WnmY+aP0slcCxRO A1A+KJwG/0ZOg+2kRAqnAYXTYL6f/xhOA8oMTZmhofBjz9CVFNYZygy91Az9DWg/XKi/He3H12b9 oHDaUDhtfljhnp9PiJJngcKiiF0kygQrEgOVAjLGLIgAWLaFrbW1rTMaYymEAwXBBolBWqJswHnP wcWO+FPWD5ljxIWcrYilgj8l/kedQOPACdIWg9rkYLuJGAkhcThbMzTUG1OUgzO4kbmgQwusM/Ms NKDIgb1HmZOqQVpisShLEtkImIFc19cqfgmaG3Ehzc2ozeLELkB6QC6e2ALi2CPBO22OskMR/xEH BONoY0oshqh44HjgIMUC1cwUZW2LsQTHcP6G4ZA2qA+r+3Dc0KAuLtmXpfoBah2IoDUiCSMkkn9Q 8egtpMkDZK0DV5/Qw/P4olzkPOQcUID0MAj4cj3MX0hlW5TKRPWxHvLN1wCmcnwdPeT9hnr4LZ4C i5RQCG7uuMC3g0XZO6Kx83pGWlU4CFkhSSsJU9QHVFQQgw+4/kJBQiEq/82mf/KXoCSTJ4xlFEdB iBVsmTkK3HYHB5PYHmtb4mQADQJYgg2xUcS5BLcsCRZpgWbrhDYn9szUZX5crNGknpsTL5xQWBfo UWQObuwjnZDE2wF+uQwdFvnptFhP/ng6XVxIW0NF1hP0ou/I30AB0ooA4Mu1wmRB/hc/neiBj7Xi h6KZAreJ/xLNFLkjmxcK/2ssTf8MtAttzsdgv2+PdjH/pM5PzyTTs1LQLhDaxe47o12qlpSIr4Nn +DzaZWPuUnKxFNol6yugXb5QOkBH+xdJx99HMvxtLFT456Tjw7AgHeHLSEf40tKxseg7SUf4x9Lh /UnNy0mH1PeTDmIr/5dxLpe/M86FNv9bPE2+BOeSlPfnz5Ru2h8N5wKewoL6wQ7UGUEnrQqPg0sp doAeC+4vCAG1NgDwzBYsBTpdBS6twNNVV4n5YQ5Q+/kW+vGMBsUOXv+901WMpLIob5v4+2+b+N4N /HcdIVl0QIkJIKsANF0KAVD4Jx9QIpf9pfnJR03If+R06vmYfJSEcoSE4qD8tzkokygOSoqD8js5 KMED3/N7xxQXCcVFQkVWX4qLhOIiobhIwPCvcZHoEE0uZ6L5hSVdoYmmF2jN7iBemxEtWNDYA1PI BtKnAQ5QUy333XIBXKiBmB3wmu6TuvRJ16AZiAVcAE1imgXJtgZTHIgttCWZh+SythHrp/1M+5YK IsT8fTR/7TfLBeAv1v21w9+t/7vvUPywGwCU92H+eX6yYUNGIpHTKdgRiuFPeR8mxfCnGP6U92FS zg6T0yoA8irgBzk7THkfJuV9mOQ0yvswKe/D/Ee8DxNkfrT4PPMjr9o882Og2iA8+/DIruYkzdaP mB/f9dzfXR+yi3GXR4ROQb+GgQGz6t5TcrpNeUzpzQw737cJanmfS0F/lvlxKmRFZvwsxPzoxZCS MqNjusD8KKukZKOurVUn6uavtzlznR+PY/FAMlyZS2U3b61imMVPPiO6CBeeU3RwA/jEZfEdxt56 QW9/Cr8F19pRysfyWu291O5NtXpca1G8tdhw7ki55oRSvmQYirX2AMj86CfDCjI/+oLcjzlUqCvb JMKUXNd54u1B5kd2H12Q+VEqke9GDZn5caeHa2tglR+nmmWIiZ7iwNEKTwyjV5h+rGH46XSjVzVy Xds55G7CGLebdNpEhYydFzXX/22MU3twgCoHL/JWhbHydzVBgbqi2XTFwdRxGLv8YwlE0pCSn8Rq LuWgp6x0J4NTAyfcp0q0ceVmCbNWG1fz+r4M0UicGovTwU/rNB/VrzW7LpqudL9BmPM+f9Vzn9WF +f0Xuu5m0sVtj547o8F9zsRn/7AmS33wKZzby70C3FaZEqc3C8QnbttOZx/YF7vT6+bKsgHx4/yD VjNHJ2V8ZCTyen3lTxWtRCpHm7jqhCQq3pll62VM6h1lR+YGryX0SvWlt+a0m89oPdBzdT0O7+Im bGNM0tM1Vi7VoWp8qdrkErV73an8Q2MjBqFpF5hn/OMJ/lmVwgeMnpyjvYbdJ2h5+xDHJentYs2d LFnyxvWScnL0go0PQ8xFZtVtaE0qRKTOuUR0awogua38XA1DVVTpNo6uM3z8JBrXLoKwQoRnuzXD Cbu6fHouYmENVxFXUG03aHmlhPm4dyVlPqJOkW66vL1KrOZc+g5W5thy7i6MuN9qDAHR/EJFcsBX RdAKdmCj8jNdI9Yb+84bJUa0b8+fZvObm0Icqu3hCzN5+9xwjdZhz2wRzzSaFc2nkrO2pGdHNCSw 7de+9yY58sSN6P1jVuNh5eI2bN5Zc3zslbDWMz2MPiXWLazUjcVMd3RvvjTYl5y3YyzS35pKS7dK UM9uzcgo8pdiTrnm7PanEVaIm/njax92qT0ZcrHjvKP/Yjgjff+DQyP3orvZ71h243Mf5Om1XK5x pr7e8YhE/NiTGpcRcFky3SJwEfHjRQHlFeV3fuLRkiinG4TlB+WSiB/tHfejAgjlIPGjx2DjFpD4 kUf2hdjFT4kfaQqP1HEvRfzIdxY2ELDy6T68LLxgAs9chpPK+5l79inskGDTyuywGVTILSsVm3J0 Rsy1GW64jVbh7LaRzMGzTixT9g0aU80OMI6tHQGrO1o8NGD/196RwFOZfe97lpB4UypZ8tKmKSJC KVosJdukRSJRzxK9p/dEaYgZVP7taWNU/0yNaZmmjJSSKC0mWkxFGbRQmkxGJUv43/Mtz/Ok1N/U LO++3/2+793l3Pvde+79zj3n3HOLp8bay5QbHFmlvd7e4prFXaR0P+bXtKgx2tXZ67ZvOXVPzmxa /xfpm22TOcuNgu0cTtcb79Y6arih91TXk6F5r7wHN7m+WFPwLPnpWo3YmLXJJZy1q40Pz142ZV6t 1Yjbw7MvyAdrps5KvtNLzcgrzubZOkXZVZvH9J41MMQ2nqNvE5X71G6/c9ERt5aZWa9Tnd318pe5 NKhVXT3z81bnS1vGZ8gbZlzIlq4Y6OA/5/dFi2+EHOIP+2nw3UDHULP4G3OeeRqPmPGbZbPsFceM pJNrvYLXND7Oy/U3d79tc9tw7f4Z+09lxV+4ckcx5KpWWl9pqVsHfWNeXznxdcIfRsWPrVMis46/ vBttm65+yM/Jp1uIgcmaQn+fGwLBuay8HkNNDAY2fJlcOv94fOj+8C1Dwo7WX1qVoBmbqB675IU6 9/mjml38RxVxXyc47zx53Tl9uMm2a1dcA8xr7nnnZuXNuNU0ZHiYkuB5XPz9CrkHMV79lzza/13G q8hd6+cZ5O/dpiFwTt95YfPSi0mnVsTmTR0wrulCdoHcgzVeY4+lZ/Kv2bz87j95U84o6v5R2G/v DkXF8uXbf3V/NUdPcZ2pqtqSUQ/Tz1+WyfEe5BFTItB/Ma/CfGHC9zcGVLkb+zRes87LZ+UU9sv9 I5//JKnhjJfh5pGTh45uXGttsL6fbsA4XlT9lZwZ4/3dk81Cnu0sMLxjn3fm872qFw+svqKioT96 hXtyTsVALW56RjBX50K+/YgS/UCdcfHTlzorqx91GatZ4FJwdSo33+zEmN0xCdk2e7yeb1I2KR88 jBujaqJSYLxF3XK2Dz/0yZ19j/aGvOyT8B+3OlPfewMv1e3ZoatkvjnZpNbC/9C9Rb46XMvJmx7H 70yfIpjtmrgr+ua+YX2Oj+qj411p16fQd1jMZ2EHl6uuVVddsuqHW8q6Va8/9x+a87jy7tRzd9YG Tz+f+GT2s7mui37cNv3K8Z26+5p8wzZ8dtNM+xxh93H+OJV+rim91TXWqBmEqTpeSMqKjHTKLNFS 2kvafeSnnMnbfix8B9h99HEl7T5+B3Yfr/fvpxgTU1ykKmdjbSpvdZ8d4oCrGp15c0LmpC/NteIa X/18JEt2vuPzWRm5SXWCDWora5aav9B8alYYdrzxkOERj4PemQMPZ+bmVE2sMTmfklpQsPWyqcmv 502KWrbcf/yt/dDiKb3ieUtZB+LurnpR4XxYLq/OI6mflteJORqleuMOpK/6NtxRw6fXD+erxwX/ NNeltt/CKr9x5gdr0g481a8yfzKpccvnK1NyD4f5LL4YHG7feJZ/2vZyPjflmz7TxpiMKF+4yGSJ I2+Hn4JyVdWxVWn+3QpvNPWvS/Az2aO/o3xn7aHeTb4BpXP3+az3mP60Ke+we070keywpVUxQQf9 Z9ndszj6hUFKtb8Kr4eF+49ffO/1Iu5317WDjVK8fe311tuuMJBZlm+oui1BsHyb3YMLJ4O3uulP u213LTFpjEPYjNKLc42GNw+YNyNLTwWDKomZ45X8lfO8S/2PZwdbpZTWznS6Zbdi8K/x7Koh0T0f ZpjsuRKtd3i4XM6uKYMqhhg1x/bN+PZlzO4j9S1Sa7zSbL22ORU1re52Zj3/bLfJmuGHs8+VGJT+ 5ixbadO/9qyae6NDnHycv07qief6Tvn//TLqhiszUKNcMy5+ekSTjoVNPavc3zxiSdzPOgq1mr05 MrZmua++mPfqefjSoqulu75tfvl9amRNmeH4S+jO9uKQ745kDt+//1jA8fMBE2fGqWk+CVVxGbv8 6DSbOcb1tpU1l1N/nmX3+lwK/37x/plbcii7j96OicrH0p4rDy0Fu48XB5wvGbDUZnytdmjuTm5V wG4LD6sWpndT7dBSgb/jtP5XM4+k/WKhfim1uch6wEtHT6XDI/KS6nRurwx88vWGU8rS4bUDtYoz G2av3PdK+0xSNc/8er18Wf/8vhErLnowm6OMe6g9rMlgvl7TkIla0NmlZc+mFjNLPHJ7N0+NyVFo ufCL9b2J/jPrzHpuUFAu66XQUvJLmkp40eOMkNCYcJcvTz8MW7fSOdbsjpdSYu4yHbUnG3K0JzfM K3bw1LLdn7XslENp+pNYy25f34tp2mSqujN3T0NC5KMk46IzITduXJviETnhdEG9hoydxTbT4Ia6 wdGVpYWhv/1UN2Rz/U25Kb1sp4g6FWZak0Uj+94pXkaj12T7sosWOU0t6Ruupi14s91HjRPKZdKB mVmOESvVG6zKGgNq+l3b1axR3fRcpqx0Q7NuoNbZZ5ZFK7/auSKsRmtH45Kaxy6vrtaGBRVoax3s bplYmX0noryxovz+g4rUvX+smPTHj5tGjK18xn6szU/xLQ1eYje23mhXZWXAyop7GYlVl289O/tj 9/JT1b0Lo+uNy0qHFMqt883RC/6pX+qQ1/4+rt33+0fpJl/fPsw4pUV32Wn5eAOr7rnXFW/PniTq vqpe6WXxdChoHLMIIpyFWONBa5eFtIGjJma78ek4hDa6kMS6qO3Ghz3h+f/TLiY13f8d2sXg/qFb 5ACVSNEAC3FBhk2hEItCIVscdjeKzCaqoG7dBQrq8uhvgkLNLQhJKzCRuINKlUXvrql39GUd3CSH hg9NKYKdBjrdSHudEO+LyG4JRCR7BHiI0DDnEdkxOgyyISYwYOcCQnYMsvECGCSMZQxSqhnFIFks GxkkH3QHg4RL2wIFOc70Vh0YAcFNA/mHs1B9xI/Lno2jCT6aAycohMf3FxB5oSFpe6HsmQIObhQ+ hLthP3msmxOf58P3XMy29sNZ3TgCHset1WynI7C+OG4zOIsDA4Dx5SYENJnHD+QB74PdGik0/qkX yAvqoGyOAMIBOw2N0AJ4BnFJa4lOvBAO34nnh9EV12MCjnM65V0MmyvgecLvxxdWhmQxiOettmWz YrMZAKseezxW0GoZUo4tRbQ/j2WvCP2Ee0DqNBPkR3g6RWQLD5FVRqpEWpKtQrp0nDGXSfYZpJBD lHyTQE0IGUiESCN1NMPByUkFXaomzfPCUFRRDqbgKFCpFYhU0JcvpNrChBoqUyEqRCppjBGAU/Rg gIHWnUk/KTJzmenEhhtpRg8Cx14z6d0rEKpLYVoDkxRPwYtpUzGMNik0ZQeganSNeZaYIugYGiLR IFQok7hXCyEjodMW5hNN2VoSU6QkKyRaElPs3loyuduGDJUSgyclAk8ZwxvXLiVdVykh3HfXzBBD SmS+u2ak3PvdNZPD8L5hvrtmJFy6n8XhQqy69GeMEClfjNPidYLZorHtZMUQhSNNYIs8weiDJxUi LYvIdZNSHThN59cmbfjSeWWomtIwPDw8RGBAnB5DlbgzGaRV6lEKx9E+Qrj6Fnks0sIfF0U0AF81 8B3+aRJPSsSzBv6nhP+p4XGpRvz64pGpSJXHoMpjtrm3by9HxhipOjwfi7fXm94EZpxGZhnVGqBx wyM+EFaE9hXoXL2P64NkhPpfgOisdZELExyvfhbzBB1AJ4c9Fk0bcWfaWBc8ZwEj/yylztL2IyZo X8A7XE9K/wxejZzPOumoaW8yUTKf0j1jo5m4DqAN11mnhme3FhH37hzkN02XepbppL5bR06HwEay p9/n/V0oCkZ8rIjjOXynRyloMBKJLw0ngItgDme1w883jTtxWPIUrPNEjfVgT+IHQOlFQblCHDhL n5ILXxt5PJJ64BqzPrB+9LuOZsK76gk4uIY9MMy3j8XWuZCcZ1gUcUjOMwwmU9t5uSCIs7j9PNP+ Cyjq2n4xocWkUHvXEf1GvOrNvJvf6KmztmzH9NuI+h8scZiMWBiRmJ6MP90iZjWj40XMQ+KpqxQQ ZbtQAVFWm03BcsZDdzHywrkB2vvDYuJ6/Z12M4oqM8KAYiPSfYzdjKLKg125mxHeSU7k/7vutNIj Uyyc9pLdjBKlxn+rUuMXn16pUYFKDbES9cWO1BclNhxhi10Xbkr0Ed2UKCyg60p4475Ev3/ivsRQ Bj08O9qXGCocoKQy0PvsS4SvEhkq2YEo2YEo2YFIhn6CHYioTXH/WAmUcjT8b2si6bcohNy3ktlE JVAWXSCBUkCdkkDRbUUTaQBelgLfjMlTeQoUKEBCn0FXKyESLWDBAAgLsh2Yymn6CfoQkA6KANks vBpQa/DqQOgBVQbKvWxEUt3a2A/EfhAid8sBnQcDwxORfDJYcA7HHhgLwHeFzhiJvTn2BtgDOWuI SDnRaESuFoD8hoULkLTQjGbYAwkNMhBXBMQsLHqAxUG+52R8t8TeCntrRMpTpmA/FXtb7KchwvQl sbnDAXtH7Ich8lMEnyVn7OcjUlMV9peCpj4MbFCS9sJ+LiJlTu7Yz8K+CZcJ5c6kyl+ASFKeg703 9rC6APkaDPlFiPwEAmthMfbAEgCZEMjdlmDPp2B8iHtb/9OL7a7uf6hrZ+oL/QZtLNr/gA90/wMu dNT/H9oe/za3kZ6yeoqfcoh2AT6ATAXu1QyZTvFQYXwBD9WXGM02HB7fx48n0JuGSSAfP08u108w gRPA1aPZtnoCTl+MTyyMXyyMayyMY3IYb5QwzsFpnnLElUXwYTUpzjOEteX1/kW5tG9pJRgZ0Erl +F6rDHMejB2Ps5seBGXCGHshJYU8ItvIjtt8Z1rdu7ntEQS3fQJuP/EWgrwCAL4Q0ZQBTM3QQJYc IIyE0m0ijkHFwxC3wouIhUAIOdpZsZ05fEz7CNokgnnCOQDTSuwZfkGYiCIiKW4d7IymGXemVJ6N iJyHdlAVqUbkG8E5oVBPIHWkqTQwH3k4TbX0sJk51ZJIDaXRdXXAyxYiKUskcBauH9AKNO/Rkrdg KVCzM/CqkIAJugYwd8PcvgLPJhPxTGKJZxZL/KSPZx1j/EXSx/918YxjgEON8ZMpvlrhny6O0cfP cDXFX5zRRD5T7MOId4T2gDnSymGk9URLtoH+GLa+vsHokaaIT+gDQGWnG0wUNr4V13GKHc+Hh8fi KJwQvd21xZ/FW98Pf9puXwQowJcQp6P+xD1h/n/iEumj8iKIhQswJDhcX08cxxYs8MT0v1+AX9By oqJvY1YEvYNbAQswDl6ujDdvy8CAahOl01vP8EJHjA9BZSVy6grDO8oOuXUJ+DwRKK1A2I5cOm/7 pZYoNC6PzeXg4kFXR1gWFKHHZk980xKNYHT82RwMs86yIdwQvehyZnTEhnCj7s7CkUAiewDzI7AW 7P7EcfNJWQsE8M4zFzjLgjhcAbWkJ/LihL6ewRyR9TsPo6qwmTyJ1ffYHm9Y43c5N6KDgfJX5UbA guLN3IgEYdgYRA+McAQD4xhxLSHDGJuFsTSvIoG6j6Hu4dR9M6Idien27QbNP4rzAGuW9+I8WNBv MlII/X3Ph9hJNClp0ZsIYwmTRsCF1HNWlAaDz2DReyIT6MRWi95achAuVV3EgHtbi96GsYO9Bz3P k+NuX3HiumK5mtCitxxJr0F6WK/SFqvV8IXNFD2lIWjSRjGL2iDloS1qBzIPMrJV5su+yZa3MgpG HdnyBq0nusz+cMFNmITLhLU/2PKWwSUbTd6IIokcmbh9mGKCU0B7WnAK9D0pOKXrdU0mkOnU61Y3 qNcIosw3WPq2REInaukb6ryOCCVxg6x3MkG/dWal1APGKCx2B4uAB7+FDddebCADB4vEIOD4YaQE ZDmg3FMkpxBRpduZFoeL4v9vWjwiIoKQMoOEGe60afET1ysIxc2/y3EVKlbiaPqxjqsIaleyVLuS ScPzgcqS4ypI7Ij4yMdV/PKxsCNOHDuMrDuLHSMlx1VQx1WwP/JxFYMGfvhxFR1/4jpzXEVUu5Kl REruuuMq2tfyjXiBa/mxj6vYtBX6mYUK95HHVaQeIo+rWJ6M0PYDAKWtLAYYJ3k/kPX/RLKYVhhI oosp0cWER4kuZufSS3QxUQQSiZMRiWNQcRJdTIkuJi3mJeYAYfUkupjor2dKUiKLkchiJLIYcBJZ jEQWI5HFCNFTIotBfy9ZjKgaqOYR+N/Wlg3swlyYSWajWQ8fy/0PUEsBAhQAFAAAAAgAwnpsLSqR JIU/OgAAAOgAACAAAAAAAAAAAAAgALaBAAAAAElFVEY1NS1SU1ZQdjIta2FyYWdpYW5uaXMtMDEu cHB0UEsFBgAAAAABAAEATgAAAH06AAAAAA== ------_=_NextPart_000_01C28C91.F414DDF0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 15 06:06: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 GAA04994 for ; Fri, 15 Nov 2002 06:06:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFB8N916386 for nsis-archive@odin.ietf.org; Fri, 15 Nov 2002 06:08:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFB8Hv16379; Fri, 15 Nov 2002 06:08: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 gAFB7xv16359 for ; Fri, 15 Nov 2002 06:07:59 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04975 for ; Fri, 15 Nov 2002 06:05:21 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAFB7tKV009020; Fri, 15 Nov 2002 12:07:55 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WWLG4B2K; Fri, 15 Nov 2002 12:07:55 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Nov 2002 12:07:54 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE1C8@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: fefc78ee ca231590 e0b3691a 00000138 From: "Georgios Karagiannis (ELN)" To: "'Bob Braden'" , nsis@ietf.org Subject: RE: [NSIS] General comments on draft-ietf-nsis-fw-01.txt Date: Fri, 15 Nov 2002 12:07:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Bob I think that I agree with many of your comments. However, it will be great if we could discuss and agree on the terminology regarding NI, NF and NR. Due to this terminology you probably got confused with the definition of the sender and receiver initiated modes. Related to the definition of sender/receiver initiated modes, we wanted to actually say the following: * sender initiated: is the mode where the sender of the data path is initiating the procedure of installing the reservation (requested resources) states * receiver initiated: is the mode where the receiver of the data path is initiating the reservation (requested resources) states. Best regards, Georgios -----Original Message----- From: Bob Braden [mailto:braden@ISI.EDU] Sent: woensdag 13 november 2002 20:36 To: nsis@ietf.org Cc: braden@ISI.EDU Subject: [NSIS] General comments on draft-ietf-nsis-fw-01.txt I finally found time to comment on the Framework draft. Sorry this comes so late. A separate message contains interleaved detailed comments, issues, questions, and disagreements. This message distills out some general comments. The Framework document represents a substantial body of work with much to recommend it. I know from experience how much work is represented here, and the authors deserve our praise and thanks. However, I also believe that considerable more work will be needed. First, a somewhat philosophical comment. My most general uneasiness with the present document is that it seems at times to float in a void. It seems a bit too top-down in flavor at times, without enough grounding in the real Internet issues. This gets better through the document, so that I generally liked sections 4, 5, and 6 much better than the eaerlier sections. It also seems a bit disconnected from the significant previous history of Internet signaling. Many of the technical issues of Internet signaling have in fact been explored in the IETF, principally by the RSVP working group (although not all of the conclusions made it into the existing RSVP v1 RFCs). Many readers will be familiar with at least the general concepts of RSVP, and it would be very helpful if the document was explicit, at least in a parenthetical way, about places where NSIS is taking a new tack, as well as places where it is covering the same ground. In a few places, using existing terminology where it fits would also be helpful. Now more specific general comments ;-) 1. I believe that the document would gain increased depth and credibility if it had a few more references to important and relevant academic papers. Particular examples might include YESSIR, Lixia's multi-level model, or (a small selection out of the corpus of) papers about mobile resource reservations. 2. There is a lot of good material and specific discussion, but there is some redundancy. It probably needs a serious hack with a text editor, moving blocks of text around and deleting redundant material. (see detailed comment message for examples.) 3. I would like to suggest that the only occurrence of the 4-letter term "NSIS" in this document should be in the combination "NSIS Working Group". All other occurrences of NSIS should be replaced by something else ... e.g., "Internet signaling" or "signaling" or ... whatever works in the particular context. Another useful term is "suite", as in a "suite of signaling protocols". Curiously, the word "node" almost never occurs in this document, yet it is fundamental. Signaling can be described abstractly, but that has to map into real messages sent between real nodes -- end systems, routers, and middleboxes. This may be just a stylistic thing. 4. The document tends to say, "Oh, by the way, this is not *just* about QoS", and then shortly falls into QoS-oriented terminology. I think this is the wrong orientation. It should rather be: "This is about all forms of path-related Internet signaling, such as QoS setup and control of middleboxes." A deeper consequence of this is the need to be quite precise about terminology, to make sure it is sufficiently general. What is the purpose of "signaling"? I generally use the Computer Sciency phrase, "to establish state in network nodes". The document often uses the term "resource request" for roughly the same concept (though it is not consistent.) At first I thought "resource request" should be replaced because it is too QoS-specific. However, it seems more in keeping with the existing document to simply define "resource request" in a general way as equivalent to setting up state, using a very general notion of what we mean by "resource". I think this can be made to work, but it needs a careful paragraph in the Introduction and strict care to always use this term. You will find a number of detailed suggested changes in this direction in my detailed comments. 5. At many points, the Framework document seems to assume a simplistic model of resource reservation -- that it is necessarily one-pass and can be achieved by a one-way flow of signaling packets along the data flow path. This omits the potentially important cases that require two-pass algorithms, or those that use one-pass-with-advertising (e.g., the IntServ Guaranteed service.) The WG should beware of simplistic assumptions. This shows up most directly in the terms NI and NR, whose semantics are sometimes confusing. Of course, *I* prefer the abstractions p-src and p-dest that I introduced in my 2level document ;-), but perhaps NI and NR can be made to work. However, that will require careful definition and usage. For example, RSVP v1 depends upon signaling in both directions, using both Path and Resv messages. So, for RSVP v1, both sender and receiver act as both NI and NR. Some of the discussion does not seem to encompass this generality. 6. The fundamental architectural picture in Figs 1 and 4 seems at first blush to be obvious, but the more I think about it, the more uncertain I am. The idea of a "co-located NI&NF" seems to conceptually define what you expect to be in an end system doing QoS signaling using the new protocol (and indeed that is exactly what RSVP v1 assumed). In particular, an Internet end system has to have at least a primitive routing/forwarding function, because it may be multihomed and/or have multiple first-hop routers. Also, for QoS setup, at least, it is generally necessary to have an (inner-)RMF in the end system as well as in the routers. (as shown in figure 9, which contradicts Figure 1!) These considerations probably hold even if the NI is not an end system. In fact, now that I think of it, it seems that there "co-located NI&NF" will be the normal case, except when a proxy is the NI. Iin practice the NI and NF functions will hopefully be only a single protocol entity in the end system. You can DESCRIBE it logically as two connected conceptual boxes, but this may not be very helpful to the implementor or in detailed design. In other words, the seemingly plausible picture conceals a deep issue of modularity and interface placement. Even if we decide that the figures as drawn at the best model, some discussion is needed about how this model maps into the real world. 7. The path-coupled/path-decoupled dichotomy is not all there is. Thinking about this space, I was led to introduce a different dichotomy, "path-related" vs. "path-unrelated". The NSIS WG is primarily focusing on path-related & path-coupled signaling, but some would like to also handle path-related & path-decoupled signaling. However, there is a 3rd class of signaling that has no direct relationship to any path; I called this path-decoupled. It might for example be used to configure routers in a domain. This is still signaling, but not the kind we intend to do in NSIS. 8. The text tends to imply the model of a signaling message passing from NI to NR through NFs undisturbed, rather like IP packets passing through routers. (See for example the first sentence of section 5.1) In some cases this may be the wrong conceptual model. In RSVP, signaling is best thought of as hop/hop; each hop propogates state in each direction, to keep certain invariants true. Also, refresh messages are generated independently and asyncronously at each hop. It is true that hop/hop action is forced by support for multicast, with its merging, so it may not be directly relevant to NSIS. However, there may be other signaling applications that will best be implemented as hop/hop signaling. 9. Sections 5.1 and 7.2 (which are somewhat redundant) seem foggy to me. For one thing, an RMF may be specific to one or more signaling applications, and there may be many distinct RMFs in a single node. Also, Figure 4 (which is repeated as Figure 7) and Figure 8 depict two quite different kinds to things [I would call them "entities", but you've used up that word ;-)], and it is not clear to me that you can usefully encompass both in a common abstraction. I see two kinds of things: an inner-RMF, which is the interface to the local node's I see "inner-RMFs" (Figs 4 & 7) that are local interfaces to the traffic control and admission control mechanisms of the forwarding plane. The WG should look into how an inner-RMF relates to the FORCES work of the IETF. Note that when an inner-RMF is a server, it may supply information to the NE as well as accept control state. Examples are admission control decisions and the Adspec machinery of RSVP v1. Then there are "outer-RMFs" (Figure 8), which seem to have quite different characteristics. This section to be an attempt to bring the bandwidth broker under the NSIS umbrella, but this may/may not fall into our chartered area. Finally, it is far from obvious to me that the NF/RMF interface corresponds to an SLA. _____________________________________ Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 15 06:23: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 GAA05290 for ; Fri, 15 Nov 2002 06:23:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFBP9a16890 for nsis-archive@odin.ietf.org; Fri, 15 Nov 2002 06:25:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFBP6v16883; Fri, 15 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 gAFBOwv16848 for ; Fri, 15 Nov 2002 06:24:58 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05265 for ; Fri, 15 Nov 2002 06:22:20 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAFBOtKV014157; Fri, 15 Nov 2002 12:24:55 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WWL2M73H; Fri, 15 Nov 2002 12:24:55 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Nov 2002 12:24:54 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE1C9@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 9bb3b4fe ca231590 e0b3691a 00000138 From: "Georgios Karagiannis (ELN)" To: "'sven.van_den_bosch@alcatel.be'" , Bob Braden Cc: braden@ISI.EDU, nsis@ietf.org Subject: RE: [NSIS] General comments on draft-ietf-nsis-fw-01.txt Date: Fri, 15 Nov 2002 12:24:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Sven and Bob One important issue for discussion that actually severely impacts the NTLP (or CSTP) and NSLP (or ULSP) model is related to the dependency between the (NSIS) protocol requests and the creation (maintenance) of NTLP and NSLP states. For example: 1) One per flow request into a node creates one per flow state at NSLP level and one per flow state at NTLP level; 2) One per aggregated request creates one per-aggregate state at the NSLP level and one per-aggregate state at the NTLP level; 3) One per-flow or one per aggregate request belonging to one traffic class is only modifying the traffic class state in the NSLP and it does not need to create and maintain a state in the NTLP. I define a traffic class as a state associated to an independent number of flows that are belonging to the same traffic class; Best Regards, Georgios -----Original Message----- From: sven.van_den_bosch@alcatel.be [mailto:sven.van_den_bosch@alcatel.be] Sent: vrijdag 15 november 2002 8:44 To: Bob Braden Cc: braden@ISI.EDU; nsis@ietf.org Subject: Re: [NSIS] General comments on draft-ietf-nsis-fw-01.txt Hi Bob, Thanks for your comments. I think we can summarize the outcome as: - clarify NTLP/NSLP in the context of RMF (according to the discussion below) - clarify the different types of RMF interactions, probably requiring different names for both types - link to FORCES CU in Atlanta, Sven. Bob Braden on 14/11/2002 23:55:19 To: braden@ISI.EDU, Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: nsis@ietf.org Subject: Re: [NSIS] General comments on draft-ietf-nsis-fw-01.txt *> *> 8. The text tends to imply the model of a signaling message passing *> from NI to NR through NFs undisturbed, rather like IP packets *> passing through routers. (See for example the first sentence *> of section 5.1) In some cases this may be the wrong *> conceptual model. In RSVP, signaling is best thought of as *> hop/hop; each hop propogates state in each direction, to keep *> certain invariants true. Also, refresh messages are generated *> independently and asyncronously at each hop. It is true that *> hop/hop action is forced by support for multicast, with its *> merging, so it may not be directly relevant to NSIS. However, *> there may be other signaling applications that will best be *> implemented as hop/hop signaling. *> *> [Sven] Would it be improved if we were more stringent about the NTLP/NSLP *> separation throughout the document. More emphasis is placed on this in the Yes, I believe so. *> current version but maybe not enough throughout the text. I believe the *> framework should talk about both layers. I also think that the focus on the *> hop-by-hop aspect may be different for both layers (more for NTLP and less *> for NSLP that is). Assuming that NSLP is what contains the description of *> what actually needs to be reserved or done, it is reasonable to describe *> the interaction with RMF more from the NSLP viewpoint. *> Yes, I think I agree. *> 9. Sections 5.1 and 7.2 (which are somewhat redundant) seem foggy to me. *> For one thing, an RMF may be specific to one or more signaling *> applications, and there may be many distinct RMFs in a single *> node. *> *> [Sven] I agree. On the other hand, if an RMF is specific to a signalling *> application, the complete picture could be assembled from many of the *> current picture in parallel. *> *> Also, Figure 4 (which is repeated as Figure 7) and Figure 8 *> depict two quite different kinds to things [I would call them *> "entities", but you've used up that word ;-)], and it is not *> clear to me that you can usefully encompass both in a common *> abstraction. I see two kinds of things: an inner-RMF, which is *> the interface to the local node's *> *> [Sven] The idea was to clarify that there are indeed to different types of *> interactions with the RMF. On the one hand, the RMF may just be a server *> which assists in performing admission control for locally controlled *> resources (what you call the inner-RMF). On the other hand, it may trigger *> a new layer of (local) NSIS signalling. This is what you call the outer-RMF *> and what is depicted in figure 8. The picture may look a bit 'centralized' *> but it essentially expresses NSIS nesting where the RMF can be either *> client or server. We are having an agreement, although the text needs some work to say more clearly what you just said. There is an issue that is partly (but not entirely) just expository: are the "two different types" should be given the same name "RMF". I think I could argue that they are so different that it would be clearer to all if they had different names. *> *> I see "inner-RMFs" (Figs 4 & 7) that are local interfaces to *> the traffic control and admission control mechanisms of the *> forwarding plane. The WG should look into how an inner-RMF *> relates to the FORCES work of the IETF. *> *> Note that when an inner-RMF is a server, it may supply *> information to the NE as well as accept control state. *> Examples are admission control decisions and the Adspec *> machinery of RSVP v1. *> *> [Sven] I fully agree. *> *> Then there are "outer-RMFs" (Figure 8), which seem to have *> quite different characteristics. This section to be an attempt *> to bring the bandwidth broker under the NSIS umbrella, but *> this may/may not fall into our chartered area. *> *> [Sven] It does cover bandwidth brokers but it is certainly not restricted *> to that. There is no argument that bandwidth brokers are currently not the *> priority for the NSIS WG but it is also agreed that the framework *> should/may have a somewhat broader scope. I agree with that, and I think the material on Figure 8 is just fine and belongs here. *> *> Finally, it is far from obvious to me that the NF/RMF interface *> corresponds to an SLA. *> *> [Sven] I think it depends on where you see the admission control. If you *> see this as part of or colocated with the NF (i.e. handling of NSLP) then *> you can think of the RMF as providing an amount of capacity (e.g. the link *> bandwidth for a certain class of service) in which the NF does admission *> control. I agree that there is a problem here with modularity and interfaces. I wonder whether the FORCES work might give us some useful guidance here? Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 15 07:45: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 HAA06893 for ; Fri, 15 Nov 2002 07:45:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFClJn20986 for nsis-archive@odin.ietf.org; Fri, 15 Nov 2002 07:47:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFClHv20979; Fri, 15 Nov 2002 07:47: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 gAFCkDv20884 for ; Fri, 15 Nov 2002 07:46:13 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06792 for ; Fri, 15 Nov 2002 07:43:34 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAFCk9KV013559; Fri, 15 Nov 2002 13:46:09 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WWL17AQ8; Fri, 15 Nov 2002 13:46:09 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Nov 2002 13:46:08 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C022BD12@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 1d35cbda ca231590 e0b3691a 00000138 From: "Vlora Rexhepi (ELN)" To: "'jmanner@cs.helsinki.fi'" , "'fu@cs.uni-goettingen.de'" Cc: nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt Date: Fri, 15 Nov 2002 13:46:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi, I have gone through the analysis draft and I have some questions/comments on it... In general: 1. The draft provides a good collection of references to extensions of RSVP. These are mentioned very briefly, however some of the RFC need to be explained more extensively than others such as [RFC3175], [RFC3209]. For this you could use the text from the: http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-03.txt 2. I find it a very good idea to include protocols developed outside IETF, but the list in the draft can be extended. So in your question on adding more protocols apart from YESSIR, Boomerang, I suggest that you add other lightweight signalling protocols such as: - Resource Management in Diffserv On DemAnd (RODA) PHR http://www.ietf.org/internet-drafts/draft-westberg-rmd-od-phr-02.txt see also PfHSN2002, Networking2002, ISCC 2002 proceedings,etc. - Resource Management in Diffserv Measurement-based Admission Control PHR http://www.ietf.org/internet-drafts/draft-westberg-rmd-mbac-phr-00.txt I will be happy to provide you with some input on these protocols. 3. The draft tends to be an "review of existing protocols". However the review itself is based on several common issues such as Processing Overhead, Bandwidth Consumption, etc. I suggest that these be clearly defined and use a common terminology. Specifically: - Section 2.3 It is not clear whether in this section you explain processing overhead due to signalling or scalability in terms of number of reservation states. I consider these two as separate issues. In the same section RSVP aggregation is explained. I believe they should be explained separately. Also the following paragraph is rather contradictory: " Still, for example, the implementation of the daemon can have a huge effect on the scalability. In [KaSh01], the authors show that their RSVP daemon is able to handle much more flows than the de-facto ISI RSVP daemon implementation. Furthermore, the scalability concern commonly associated with RSVP are more or less subject to individual's views on what "scalability" is. " as initially you say that the daemon implementation can impact scalability and than you continue by saying that "scalability" is subjective to the individual's understanding of it?! - Section 2.4 Considering the size of signalling messages the Bandwidth Consumption does not seem to be important, unless we're talking about wireless links. What was the motivation for having it there? -Section 2.7 you mention "killer problems", I assume you meant killer reservation problems... - Section 3.4 and section 4.4 The issues of the reservation identifier and the refresh of the reservation state are common for the signalling protocols RSVP, YESSIR and Boomerang when considering mobility support. However in case of YESSIR and Boomerang the refresh of the reservation state is different than in RSVP as both YESSIR and Boomerang are sender initiated, which means that there is no need to store backward routing information. I would suggest that in Section 3.4, Section 4.4 this is explained, instead of just referring to Section 2.5. -Section 5.5 You focus on the signalling protocols and yet you have explained the ITSUMO framework. Is the idea here to include framework/architectures as well? Regards, Vlora _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 15 07:46: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 HAA06946 for ; Fri, 15 Nov 2002 07:46:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFCn5q21080 for nsis-archive@odin.ietf.org; Fri, 15 Nov 2002 07:49:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFCn2v21073; Fri, 15 Nov 2002 07: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 gAFCmgv21037 for ; Fri, 15 Nov 2002 07:48:42 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06920 for ; Fri, 15 Nov 2002 07:46:04 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAFCnMB22351 for ; Fri, 15 Nov 2002 14:49:22 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Nov 2002 14:48:38 +0200 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 15 Nov 2002 14:48:38 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 15 Nov 2002 14:48:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Updated agenda Date: Fri, 15 Nov 2002 14:48:37 +0200 Message-ID: Thread-Topic: [NSIS] Updated agenda Thread-Index: AcKMkgysVCZQ3cyZQwqeeDkNlJSS4QAEwgsA To: Cc: X-OriginalArrivalTime: 15 Nov 2002 12:48:37.0794 (UTC) FILETIME=[5119E820:01C28CA5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAFCmgv21038 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Georgios, > Thank you for updating the agenda! > However, I have a comment. > As you already know in the presentation of: > "A Proposal for RSVPv2" I would like to only present the > used concept (see slides in the attachment). > The used concept is an enhancement of the concept introduced in > draft-braden-2level-signaling-01.txt and therefore, > I would very much appreciate if I will be able to present it! > Could you move this presentation to the > Framework Discussion slot? Right now, I am worried that we are going to be very short of time, so I cannot promise anything. Our main goals will be to discuss the existing WG items & related work. I will try to move you up, so that you will have time. However, the agendas are closed now by the IETF, so I am hesitant to change them. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 15 07:49: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 HAA06990 for ; Fri, 15 Nov 2002 07:49:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFCpBg21166 for nsis-archive@odin.ietf.org; Fri, 15 Nov 2002 07:51: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 gAFCp3v21151; Fri, 15 Nov 2002 07:51: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 gAFCoMv21123 for ; Fri, 15 Nov 2002 07:50:22 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06967 for ; Fri, 15 Nov 2002 07:47:44 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAFCoJQ1021466; Fri, 15 Nov 2002 13:50:19 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WWLG46YD; Fri, 15 Nov 2002 13:50:19 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Nov 2002 13:49:34 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE1CA@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: dc15af6a ca231590 e0b3691a 00000138 From: "Georgios Karagiannis (ELN)" To: "'Ersue Mehmet'" , nsis@ietf.org Subject: RE: [NSIS] Updated agenda Date: Fri, 15 Nov 2002 13:50:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Mehmet If you look into the slides that I have just sent some minutes ago you could see that I am not willing to discussed a solution. What I want to discuss is a concept that is very much related to Framework discussion and not related to protocol work discussion! It is a similar concept as the concept that will be discussed in the presentation of draft-braden-2level-signaling-01.txt. Best regards, Georgios -----Original Message----- From: Ersue Mehmet [mailto:mehmet.ersue@siemens.com] Sent: vrijdag 15 november 2002 13:40 To: 'Georgios Karagiannis (ELN)'; nsis@ietf.org Subject: RE: [NSIS] Updated agenda Hi Georgios, > Hi Marcus, > > > I don't think we should go to solutions already. > > I agree - that is why if there are any discussions of solution-oriented > drafts, then the discussion topics open would be issues that could/should > be considered by existing WG drafts. There is no presentation of the > actual solutions at IETF 55. > > John as John wrote if there is any solution-oriented discussion we should only focus on issues which are important for NSIS drafts. Best Regards, Mehmet > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: Friday, November 15, 2002 11:30 AM > To: 'john.loughney@nokia.com' > Cc: nsis@ietf.org > Subject: RE: [NSIS] Updated agenda > > > Hi John > > Thank you for updating the agenda! > However, I have a comment. > As you already know in the presentation of: > "A Proposal for RSVPv2" I would like to only present the > used concept (see slides in the attachment). > The used concept is an enhancement of the concept introduced in > draft-braden-2level-signaling-01.txt and therefore, > I would very much appreciate if I will be able to present it! > Could you move this presentation to the > Framework Discussion slot? > > > > Best regards, > Georgios > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: donderdag 14 november 2002 23:24 > To: nsis@ietf.org > Subject: [NSIS] Updated agenda > > > Tuesday November 19, 2002 > 1300-1400 Afternoon Session I > > WG Status, charter discussion - chair 20 min > > Terminology Discustion - Robert Hancock > > Requirements - Marcus Brunner - 20 minutes > http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-05.txt > > Wrap-up - 10 minutes > > WEDNESDAY, November 20, 2002 > 0900-1130 Morning Sessions > > Framework Discussion - 50 minutes > > Next Steps in Signaling: Framework - Robert Handcock - (15 min) > http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-00.txt > > Trade-offs and open issues with path discovery and > transport - Henning Schulzrinne - (15 min) > > http://www.ietf.org/internet-drafts/draft-schulzrinne-nsis-casp-00.txt > > A Two-Level Architecture for Internet Signaling - chair > - (10 min) > > http://www.ietf.org/internet-drafts/draft-braden-2level-signal > ing-01.txt > > Sender and Receiver Orientation Issues in NSIS - Robert > Hancock - (10 min) > > http://www.ietf.org/internet-drafts/draft-hancock-nsis-sender- receiver-00.txt Analysis work - 50 minutes Analysis of Existing Quality of Service Signaling Protocols - Jukka Manner - (10 min) http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-00.txt Nsis Threats - H. Tschofenig - (10min) http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-00.txt RSVP Security Properties - H. Tschofenig - (10min) http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-00.txt Analysis of Existing QoS Solutions - G. Karagiannis - (10 min) http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-03.txt Analysis of Mobile IP and RSVP Interactions - Mike Thomas - (10 minutes) http://www.ietf.org/internet-drafts/draft-thomas-nsis-rsvp-analysis-00.txt Discusion - (15 min) Protocol Work - 20 minutes - If we have time A Proposal for RSVPv2 - G. Karagiannis - (5 min) http://www.ietf.org/internet-drafts/draft-westberg-proposal-for-rsvpv2-01.txt A Firewall/NAT Traversal Client for CASP - H. Tschofenig - (5 min) http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-casp-midcom-00.txt The Use of Bi-Directional RSVP in the Wireless Internet - Kamel Shaheen (5 min) http://www.ietf.org/internet-drafts/draft-Shaheen-shahrier-nsis-brsvp-00.txt Signaling Interworking for IPv6 Network - Gyu Myoung Lee - (5 min) http://www.ietf.org/internet-drafts/draft-choi-ipv6-signaling-interworking-00.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 15 08:01: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 IAA07266 for ; Fri, 15 Nov 2002 08:01:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFD39q21490 for nsis-archive@odin.ietf.org; Fri, 15 Nov 2002 08:03:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFD36v21482; Fri, 15 Nov 2002 08:03: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 gAFCeOv20665 for ; Fri, 15 Nov 2002 07:40:24 -0500 Received: from beamer.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06715 for ; Fri, 15 Nov 2002 07:37:45 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA15536; Fri, 15 Nov 2002 13:40:20 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA06920; Fri, 15 Nov 2002 13:40:19 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2656.59) id ; Fri, 15 Nov 2002 13:39:45 +0100 Message-ID: From: Ersue Mehmet To: "'Georgios Karagiannis (ELN)'" , nsis@ietf.org Subject: RE: [NSIS] Updated agenda Date: Fri, 15 Nov 2002 13:39:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Georgios, > Hi Marcus, > > > I don't think we should go to solutions already. > > I agree - that is why if there are any discussions of solution-oriented > drafts, then the discussion topics open would be issues that could/should > be considered by existing WG drafts. There is no presentation of the > actual solutions at IETF 55. > > John as John wrote if there is any solution-oriented discussion we should only focus on issues which are important for NSIS drafts. Best Regards, Mehmet > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: Friday, November 15, 2002 11:30 AM > To: 'john.loughney@nokia.com' > Cc: nsis@ietf.org > Subject: RE: [NSIS] Updated agenda > > > Hi John > > Thank you for updating the agenda! > However, I have a comment. > As you already know in the presentation of: > "A Proposal for RSVPv2" I would like to only present the > used concept (see slides in the attachment). > The used concept is an enhancement of the concept introduced in > draft-braden-2level-signaling-01.txt and therefore, > I would very much appreciate if I will be able to present it! > Could you move this presentation to the > Framework Discussion slot? > > > > Best regards, > Georgios > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: donderdag 14 november 2002 23:24 > To: nsis@ietf.org > Subject: [NSIS] Updated agenda > > > Tuesday November 19, 2002 > 1300-1400 Afternoon Session I > > WG Status, charter discussion - chair 20 min > > Terminology Discustion - Robert Hancock > > Requirements - Marcus Brunner - 20 minutes > http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-05.txt > > Wrap-up - 10 minutes > > WEDNESDAY, November 20, 2002 > 0900-1130 Morning Sessions > > Framework Discussion - 50 minutes > > Next Steps in Signaling: Framework - Robert Handcock - (15 min) > http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-00.txt > > Trade-offs and open issues with path discovery and > transport - Henning Schulzrinne - (15 min) > > http://www.ietf.org/internet-drafts/draft-schulzrinne-nsis-casp-00.txt > > A Two-Level Architecture for Internet Signaling - chair > - (10 min) > > http://www.ietf.org/internet-drafts/draft-braden-2level-signal > ing-01.txt > > Sender and Receiver Orientation Issues in NSIS - Robert > Hancock - (10 min) > > http://www.ietf.org/internet-drafts/draft-hancock-nsis-sender- receiver-00.txt Analysis work - 50 minutes Analysis of Existing Quality of Service Signaling Protocols - Jukka Manner - (10 min) http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-00.txt Nsis Threats - H. Tschofenig - (10min) http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-00.txt RSVP Security Properties - H. Tschofenig - (10min) http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-00.txt Analysis of Existing QoS Solutions - G. Karagiannis - (10 min) http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-03.txt Analysis of Mobile IP and RSVP Interactions - Mike Thomas - (10 minutes) http://www.ietf.org/internet-drafts/draft-thomas-nsis-rsvp-analysis-00.txt Discusion - (15 min) Protocol Work - 20 minutes - If we have time A Proposal for RSVPv2 - G. Karagiannis - (5 min) http://www.ietf.org/internet-drafts/draft-westberg-proposal-for-rsvpv2-01.txt A Firewall/NAT Traversal Client for CASP - H. Tschofenig - (5 min) http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-casp-midcom-00.txt The Use of Bi-Directional RSVP in the Wireless Internet - Kamel Shaheen (5 min) http://www.ietf.org/internet-drafts/draft-Shaheen-shahrier-nsis-brsvp-00.txt Signaling Interworking for IPv6 Network - Gyu Myoung Lee - (5 min) http://www.ietf.org/internet-drafts/draft-choi-ipv6-signaling-interworking-00.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 15 08:09:00 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 IAA07428 for ; Fri, 15 Nov 2002 08:09:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFDB7f22328 for nsis-archive@odin.ietf.org; Fri, 15 Nov 2002 08:11: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 gAFDB5v22321; Fri, 15 Nov 2002 08:11: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 gAFDAZv22301 for ; Fri, 15 Nov 2002 08:10:35 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07416 for ; Fri, 15 Nov 2002 08:07:56 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAFDAVKV021435; Fri, 15 Nov 2002 14:10:32 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WWL2NVAL; Fri, 15 Nov 2002 14:10:28 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Nov 2002 14:10:27 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C01AE1CD@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 9cb58f90 ca231590 e0b3691a 00000138 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" Cc: nsis@ietf.org Subject: RE: [NSIS] Updated agenda Date: Fri, 15 Nov 2002 14:09:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Thank you! -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: vrijdag 15 november 2002 13:49 To: Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] Updated agenda Hi Georgios, > Thank you for updating the agenda! > However, I have a comment. > As you already know in the presentation of: > "A Proposal for RSVPv2" I would like to only present the > used concept (see slides in the attachment). > The used concept is an enhancement of the concept introduced in > draft-braden-2level-signaling-01.txt and therefore, > I would very much appreciate if I will be able to present it! > Could you move this presentation to the > Framework Discussion slot? Right now, I am worried that we are going to be very short of time, so I cannot promise anything. Our main goals will be to discuss the existing WG items & related work. I will try to move you up, so that you will have time. However, the agendas are closed now by the IETF, so I am hesitant to change them. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 15 09:52: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 JAA09585 for ; Fri, 15 Nov 2002 09:52:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFEsK327273 for nsis-archive@odin.ietf.org; Fri, 15 Nov 2002 09:54: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 gAFEsIv27262; Fri, 15 Nov 2002 09:54: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 gAFEr2v27218 for ; Fri, 15 Nov 2002 09:53:02 -0500 Received: from iramx2.ira.uni-karlsruhe.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09573 for ; Fri, 15 Nov 2002 09:50:24 -0500 (EST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 18Chq5-0003PA-00 for ; Fri, 15 Nov 2002 15:52:57 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=tpce10.ipv6.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 18Chq6-0002j7-00 for ; Fri, 15 Nov 2002 15:52:58 +0100 Received: from tpce10.ipv6.tm.uka.de (localhost [127.0.0.1]) by tpce10.ipv6.tm.uka.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id gAFEqRe32232 for ; Fri, 15 Nov 2002 15:52:27 +0100 Message-Id: <200211151452.gAFEqRe32232@tpce10.ipv6.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: nsis@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Nov 2002 15:52:27 +0100 From: Roland Bless Subject: [NSIS] I-D ACTION:draft-schelen-nsis-opopsig-01.txt (Fwd) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , ------- Forwarded Message A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Path-coupled and Path-decoupled Signaling for NSIS Author(s) : A. Couturier, O. Schelen, R. Bless, R. Geib, O. Dugeon Filename : draft-schelen-nsis-opopsig-01.txt Pages : 16 Date : 2002-11-7 The NSIS Work group will develop the requirements, architecture and protocols for the next IETF steps on signaling. Two approaches for a signaling model have been discussed: path-coupled and path-decoupled (previously denoted as on-path and off-path). This draft provides a conceptual comparison between path-coupled and path-decoupled signaling together with reasons for why an NSIS protocol should be designed to support both cases. The collection of data objects to be carried by the protocol should basically be the same in both cases and will evolve over time as new usages for NSIS protocol are identified. The differences between the two flavors of this NSIS protocol are then explained. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schelen-nsis-opopsig-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-schelen-nsis-opopsig-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-schelen-nsis-opopsig-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. ------- End of Forwarded Message _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 15 12:00: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 MAA12453 for ; Fri, 15 Nov 2002 12:00:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFH2S401442 for nsis-archive@odin.ietf.org; Fri, 15 Nov 2002 12:02: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 gAFH2Ov01417; Fri, 15 Nov 2002 12:02: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 gAFGo1v00986 for ; Fri, 15 Nov 2002 11:50:01 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12165 for ; Fri, 15 Nov 2002 11:47:22 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gAFGnsL07715; Fri, 15 Nov 2002 08:49:54 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id QAA08799; Fri, 15 Nov 2002 16:49:54 GMT Date: Fri, 15 Nov 2002 16:49:54 GMT Message-Id: <200211151649.QAA08799@gra.isi.edu> To: braden@ISI.EDU, nsis@ietf.org, robert.hancock@roke.co.uk Subject: RE: [NSIS] General comments on draft-ietf-nsis-fw-01.txt X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> [reh] Agreed, modulo changing NSLP<-->NTLP in the previous paragraph. Damn, sorry, you're right. That is one problem I have with the NSLP/NTLP terminology... my senior brain gets them confused! ;-) Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 15 12:53: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 MAA13852 for ; Fri, 15 Nov 2002 12:53:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFHtBC04804 for nsis-archive@odin.ietf.org; Fri, 15 Nov 2002 12:55: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 gAFHt8v04782; Fri, 15 Nov 2002 12:55: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 gAFHrqv04706 for ; Fri, 15 Nov 2002 12:53:52 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13833 for ; Fri, 15 Nov 2002 12:51:12 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gAFHrkL13211; Fri, 15 Nov 2002 09:53:46 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id RAA08867; Fri, 15 Nov 2002 17:53:46 GMT Date: Fri, 15 Nov 2002 17:53:46 GMT Message-Id: <200211151753.RAA08867@gra.isi.edu> To: Georgios.Karagiannis@eln.ericsson.se Subject: RE: [NSIS] General comments on draft-ietf-nsis-fw-01.txt Cc: braden@ISI.EDU, nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> For example: *> 1) One per flow request into a node creates one per flow state *> at NSLP level and one per flow state at NTLP level; *> *> 2) One per aggregated request creates one per-aggregate state *> at the NSLP level and one per-aggregate state at the NTLP level; *> *> 3) One per-flow or one per aggregate request belonging to one traffic class *> is only modifying the traffic class state in the NSLP and it does not need *> to create and maintain a state in the NTLP. I define a traffic class as *> a state associated to an independent number of flows that are belonging *> to the same traffic class; *> *> Best Regards, *> Georgios Georgios, I believe that the short answer to your question is that my proposal already gives you what you want. I believe that your case 3) is exactly the "SendInfo" primitive of my API: the SAPU is transmitted reliably but it is not treated as soft state. Therefore the receiving CSTP acknowledges it and demuxes it to the local ULSP module, but the CSTP does not maintain a copy or any record of the state for timing it out. So I believe that we have already provided you the facility for a both "statefull" and "stateless" CSTPs (to use the term on your slides.) BTW, it was absolutely my intent that the 2level signaling model should be able to provide the functional organization in your "Architecture" slide, with its acknowledgment of the core/edge distinction for signaling. The other aspect of your slide, PDR vs PHR, harks back to the discussion that Robert and I have just been having -- how fine-grained should ULSPs be? I can imagine defining a single ULSP that exhibits either PDR or PHR behavior depending upon where it is installed. Alternatively,PDR and PHR form a pair of distinct but interrelated ULSPs. Thinking through the implications in this particular case might give us some insight about the general design issue. Finally, note that there is really no difference between your cases (1) and (2) above, I defined a "flow" to be of any desired granularity, from a microflow to a fully aggregated flow. Furthermore, the CSTP I defined does not even really know about flows, it really only knows about sending and receiving signaling messages and about timing out soft state. The semantics of flow identification and aggregation are known only to the ULSP. [There may be some issues about the specific division of functionality I chose between CSTP and ULSP. My choice seemed to be forced by my desire to provide a common soft-state mechanism in the lower layer, and there were subtleties having to the interaction with routing. There is a design issue that I have been reconsidering... whether in fact the CSTP *should* know about flows... but that should be the subject of a different message.] Thanks, Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 15 14:05: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 OAA15642 for ; Fri, 15 Nov 2002 14:05:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFJ7Tn08563 for nsis-archive@odin.ietf.org; Fri, 15 Nov 2002 14:07: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 gAFJ7Qv08556; Fri, 15 Nov 2002 14:07: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 gAFJ6Ev07937 for ; Fri, 15 Nov 2002 14:06:14 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15577 for ; Fri, 15 Nov 2002 14:03:32 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gAFJ66L00838; Fri, 15 Nov 2002 11:06:06 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id TAA08944; Fri, 15 Nov 2002 19:06:06 GMT Date: Fri, 15 Nov 2002 19:06:06 GMT Message-Id: <200211151906.TAA08944@gra.isi.edu> To: braden@ISI.EDU, nsis@ietf.org, Georgios.Karagiannis@eln.ericsson.se Subject: RE: [NSIS] General comments on draft-ietf-nsis-fw-01.txt X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> Hi Bob *> *> I think that I agree with many of your comments. *> However, it will be great if we could discuss and agree *> on the terminology regarding NI, NF and NR. *> Due to this terminology you probably got confused *> with the definition of the sender and receiver initiated modes. *> *> Related to the definition of sender/receiver initiated modes, *> we wanted to actually say the following: *> * sender initiated: is the mode where the sender of the data path *> is initiating the procedure of installing the reservation *> (requested resources) states *> * receiver initiated: is the mode where the receiver of the data *> path is initiating the reservation (requested resources) states. *> *> Best regards, *> Georgios *> Georgios, Pardon if I am being obtuse, but this distinction does not seem to capture the difference. In the RSVP case, state is being installed in both directions: path state is installed downstream and reservation state is installed upstream. Hence, you would have to say that RSVP is both sender- and receiver-initiated. Perhaps the confusion comes because we are not making a necessary distinction between a specific signaling operation and the signaling application's effect. The effect of RSVP is to install "receiver-initiated resource reservations", but RSVP achieves this effect using bi-directional signaling operations. For the purposes of the Framework, I suggest we want to use NI and NR to define a signaling operation. Then, indeed RSVP would make both sender and receiver the NI and the NR. The text needs to make clear that "Initiator" in NI is intended in this very specific sense, not to be confused with the higher-level semantic effect that people usually call "sender-initiated" or "receiver-initiated". I suggest that we instead refer to "upstream" and "downstream" signaling operations. Does this make sense? Bob *> *> -----Original Message----- *> From: Bob Braden [mailto:braden@ISI.EDU] *> Sent: woensdag 13 november 2002 20:36 *> To: nsis@ietf.org *> Cc: braden@ISI.EDU *> Subject: [NSIS] General comments on draft-ietf-nsis-fw-01.txt *> *> *> *> I finally found time to comment on the Framework draft. Sorry this *> comes so late. *> *> A separate message contains interleaved detailed comments, issues, *> questions, and disagreements. This message distills out some general *> comments. *> *> The Framework document represents a substantial body of work with much *> to recommend it. I know from experience how much work is represented *> here, and the authors deserve our praise and thanks. However, I also *> believe that considerable more work will be needed. *> *> First, a somewhat philosophical comment. My most general uneasiness *> with the present document is that it seems at times to float in a *> void. It seems a bit too top-down in flavor at times, without enough *> grounding in the real Internet issues. This gets better through the *> document, so that I generally liked sections 4, 5, and 6 much better *> than the eaerlier sections. It also seems a bit disconnected from the *> significant previous history of Internet signaling. Many of the *> technical issues of Internet signaling have in fact been explored in *> the IETF, principally by the RSVP working group (although not all of *> the conclusions made it into the existing RSVP v1 RFCs). *> *> Many readers will be familiar with at least the general concepts of *> RSVP, and it would be very helpful if the document was explicit, at *> least in a parenthetical way, about places where NSIS is taking a new *> tack, as well as places where it is covering the same ground. In a few *> places, using existing terminology where it fits would also be *> helpful. *> *> Now more specific general comments ;-) *> *> 1. I believe that the document would gain increased depth and *> credibility if it had a few more references to important and *> relevant academic papers. Particular examples might include *> YESSIR, Lixia's multi-level model, or (a small selection out of *> the corpus of) papers about mobile resource reservations. *> *> 2. There is a lot of good material and specific discussion, but there *> is some redundancy. It probably needs a serious hack *> with a text editor, moving blocks of text around and deleting *> redundant material. (see detailed comment message for examples.) *> *> 3. I would like to suggest that the only occurrence of the 4-letter *> term "NSIS" in this document should be in the combination *> "NSIS Working Group". All other occurrences of NSIS should *> be replaced by something else ... e.g., "Internet signaling" *> or "signaling" or ... whatever works in the particular context. *> *> Another useful term is "suite", as in a "suite of signaling *> protocols". *> *> Curiously, the word "node" almost never occurs in this document, *> yet it is fundamental. Signaling can be described abstractly, *> but that has to map into real messages sent between real *> nodes -- end systems, routers, and middleboxes. This may be *> just a stylistic thing. *> *> 4. The document tends to say, "Oh, by the way, this is not *just* about *> QoS", and then shortly falls into QoS-oriented terminology. *> I think this is the wrong orientation. It should rather be: *> "This is about all forms of path-related Internet signaling, *> such as QoS setup and control of middleboxes." *> *> A deeper consequence of this is the need to be quite precise about *> terminology, to make sure it is sufficiently general. *> *> What is the purpose of "signaling"? I generally use the *> Computer Sciency phrase, "to establish state in network *> nodes". The document often uses the term "resource *> request" for roughly the same concept (though it is not *> consistent.) *> *> At first I thought "resource request" should be replaced *> because it is too QoS-specific. However, it seems more in *> keeping with the existing document to simply define "resource *> request" in a general way as equivalent to setting up state, *> using a very general notion of what we mean by "resource". I *> think this can be made to work, but it needs a careful *> paragraph in the Introduction and strict care to always use *> this term. You will find a number of detailed suggested *> changes in this direction in my detailed comments. *> *> 5. At many points, the Framework document seems to assume a simplistic *> model of resource reservation -- that it is necessarily *> one-pass and can be achieved by a one-way flow of signaling *> packets along the data flow path. This omits the potentially *> important cases that require two-pass algorithms, or those that *> use one-pass-with-advertising (e.g., the IntServ Guaranteed *> service.) The WG should beware of simplistic *> assumptions. *> *> This shows up most directly in the terms NI and NR, whose *> semantics are sometimes confusing. Of course, *I* prefer the *> abstractions p-src and p-dest that I introduced in my 2level *> document ;-), but perhaps NI and NR can be made to work. *> However, that will require careful definition and usage. For *> example, RSVP v1 depends upon signaling in both directions, *> using both Path and Resv messages. So, for RSVP v1, both *> sender and receiver act as both NI and NR. Some of the *> discussion does not seem to encompass this generality. *> *> 6. The fundamental architectural picture in Figs 1 and 4 seems at *> first blush to be obvious, but the more I think about it, *> the more uncertain I am. *> *> The idea of a "co-located NI&NF" seems to conceptually define *> what you expect to be in an end system doing QoS signaling *> using the new protocol (and indeed that is exactly what RSVP v1 *> assumed). In particular, an Internet end system has to have at *> least a primitive routing/forwarding function, because it may *> be multihomed and/or have multiple first-hop routers. Also, *> for QoS setup, at least, it is generally necessary to have an *> (inner-)RMF in the end system as well as in the routers. *> (as shown in figure 9, which contradicts Figure 1!) *> *> These considerations probably hold even if the NI is not an *> end system. In fact, now that I think of it, it seems that *> there "co-located NI&NF" will be the normal case, except when *> a proxy is the NI. *> *> Iin practice the NI and NF functions will hopefully be only a *> single protocol entity in the end system. You can DESCRIBE it *> logically as two connected conceptual boxes, but this may not *> be very helpful to the implementor or in detailed design. In *> other words, the seemingly plausible picture conceals a deep *> issue of modularity and interface placement. *> *> Even if we decide that the figures as drawn at the best model, *> some discussion is needed about how this model maps into the *> real world. *> *> *> 7. The path-coupled/path-decoupled dichotomy is not all there is. *> *> Thinking about this space, I was led to introduce a different *> dichotomy, "path-related" vs. "path-unrelated". The NSIS *> WG is primarily focusing on path-related & path-coupled *> signaling, but some would like to also handle path-related & *> path-decoupled signaling. However, there is a 3rd class *> of signaling that has no direct relationship to any path; I *> called this path-decoupled. It might for example be used to *> configure routers in a domain. This is still signaling, but *> not the kind we intend to do in NSIS. *> *> 8. The text tends to imply the model of a signaling message passing *> from NI to NR through NFs undisturbed, rather like IP packets *> passing through routers. (See for example the first sentence *> of section 5.1) In some cases this may be the wrong *> conceptual model. In RSVP, signaling is best thought of as *> hop/hop; each hop propogates state in each direction, to keep *> certain invariants true. Also, refresh messages are generated *> independently and asyncronously at each hop. It is true that *> hop/hop action is forced by support for multicast, with its *> merging, so it may not be directly relevant to NSIS. However, *> there may be other signaling applications that will best be *> implemented as hop/hop signaling. *> *> 9. Sections 5.1 and 7.2 (which are somewhat redundant) seem foggy to me. *> For one thing, an RMF may be specific to one or more signaling *> applications, and there may be many distinct RMFs in a single *> node. *> *> Also, Figure 4 (which is repeated as Figure 7) and Figure 8 *> depict two quite different kinds to things [I would call them *> "entities", but you've used up that word ;-)], and it is not *> clear to me that you can usefully encompass both in a common *> abstraction. I see two kinds of things: an inner-RMF, which is *> the interface to the local node's *> *> I see "inner-RMFs" (Figs 4 & 7) that are local interfaces to *> the traffic control and admission control mechanisms of the *> forwarding plane. The WG should look into how an inner-RMF *> relates to the FORCES work of the IETF. *> *> Note that when an inner-RMF is a server, it may supply *> information to the NE as well as accept control state. *> Examples are admission control decisions and the Adspec *> machinery of RSVP v1. *> *> Then there are "outer-RMFs" (Figure 8), which seem to have *> quite different characteristics. This section to be an attempt *> to bring the bandwidth broker under the NSIS umbrella, but *> this may/may not fall into our chartered area. *> *> Finally, it is far from obvious to me that the NF/RMF interface *> corresponds to an SLA. *> _____________________________________ *> Bob Braden *> _______________________________________________ *> nsis mailing list *> nsis@ietf.org *> https://www1.ietf.org/mailman/listinfo/nsis *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 15 14:54: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 OAA16954 for ; Fri, 15 Nov 2002 14:54:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAFJv7e11081 for nsis-archive@odin.ietf.org; Fri, 15 Nov 2002 14:57: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 gAFJv5v11046; Fri, 15 Nov 2002 14:57: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 gAFJaav09882 for ; Fri, 15 Nov 2002 14:36:36 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16388 for ; Fri, 15 Nov 2002 14:33:54 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gAFJaQL22801; Fri, 15 Nov 2002 11:36:26 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id TAA08975; Fri, 15 Nov 2002 19:36:26 GMT Date: Fri, 15 Nov 2002 19:36:26 GMT Message-Id: <200211151936.TAA08975@gra.isi.edu> To: sven.van_den_bosch@alcatel.be Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Cc: braden@ISI.EDU, nsis@ietf.org, brunner@ccrle.nec.de X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> If I understand correctly, we are talking about an identifier that is *> independent of IP addresses (they could be the flow id for QoS and should *> go in the NTLP anyway) and cannot be guaranteed to be needed in all Sven, ?? I don't understand your argument for putting a "flow id for QoS" in the NTLP/CSTP. [I am not claiming there is no argument, mind you; depending upon what you mean by "flow id", I might/might not agree.] *> applications. Given this, I think it would make sense to make it a *> mandatory component of each NSLP specification (I am assuming that the I would argue against *any* mandatory component of NSLP specifications. I think it is vital for future unforeseen applications of our framework that the NSLP level be unrestricted. It's fine to say, "If an NSLP/ULSP needs this functionality, do it this way: ...", but not to mandate its usage by all NSLPs/ULSPs. *> actual user of this id will be NSLP and therefore it would make more sense *> to put it there). Maybe we could foresee a flag in the NTLP to indicate *> that such an object is present? If it is used in by an NSLP/ULSP, the object can be embedded in the SAPU. The "flag" could be embodied in the encoding used for the SAPU, e.g., it might be the presence of a strongly-typed object as in RSVP v1.) Bob Braden *> *> Sven. *> *> *> *> *> *> "Freytsis, Ilya" @ietf.org on 08/11/2002 15:42:46 *> *> Sent by: nsis-admin@ietf.org *> *> *> To: "'Hancock, Robert'" , Bob Braden *> , nsis@ietf.org, brunner@ccrle.nec.de *> cc: *> Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i *> dentifier *> *> *> My comments in-line *> *> Regards, *> Ilya *> *> -----Original Message----- *> From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] *> Sent: Thursday, November 07, 2002 5:37 PM *> To: Bob Braden; nsis@ietf.org; brunner@ccrle.nec.de *> Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i *> dentifier *> *> Hi, *> *> A comment on scope/layering of this reservation identifier thing (if it *> ever *> exists): *> *> > *> So reformulating the requirement into "An NSIS protocol *> > MUST support a *> > *> reservation identifer" would solve the first one. *> > *> > OK, although I would say "MUST be able to support". *> > *> > BTW, a reservation identifier is presumably a multi-hop *> > thing, so in my *> > 2-level model it is a creature of ULSP, i.e., it is carried in an *> > SAPU. That's good, because non-QoS signaling applications probably *> > don't have any reservations to identify. *> *> I think we need to work through this. *> *> 1. As Marcus has said, we are signalling to set up something, and that *> something is what we want to identify to be able to manipulate - it doesn't *> matter if it's QoS (and called a reservation) or something else. *> [IF] That is right to the point. I just want to add that that something is *> separate from the flow but used by the flow. The main value of the *> reservation ID in my mind is to enable referencing that something *> independently from any other characteristics of the flow. *> *> The v6 flow label draft calls this something 'flow state' so this *> identifier *> could be a "flow state id". Would that be a better term? *> [IF] I don't think. See the argument above. *> 2. My feeling is that this XXX-id would be useful for general signalling *> applications (i.e. if you use the signalling application in a mobile *> enviroment, efficiently moving the state is something you want to do *> anyway). Also, providing the facility might be tricky, and might require *> subtle interworking with other protocols (e.g. mobility ones). *> *> In that case, it be better to provide it as a generic service rather than *> solving the problem for each signalling application. *> [IF] Agreed. *> 3. So, wouldn't one want it within the NTLP (lower layer)? *> [IF] Absolutely. *> 4. Or, should we be thinking of some kind of 'core' NSLP toolkit which has *> these generic facilities? *> [IF] I think it is good way to move forward. *> Cheers, *> *> Robert H. *> _______________________________________________ *> nsis mailing list *> nsis@ietf.org *> https://www1.ietf.org/mailman/listinfo/nsis *> _______________________________________________ *> nsis mailing list *> nsis@ietf.org *> https://www1.ietf.org/mailman/listinfo/nsis *> *> *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Nov 15 19:00: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 TAA24367 for ; Fri, 15 Nov 2002 19:00:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAG02Lm27520 for nsis-archive@odin.ietf.org; Fri, 15 Nov 2002 19:02:21 -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 gAG02Iv27513; Fri, 15 Nov 2002 19:02: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 gAG01tv27498 for ; Fri, 15 Nov 2002 19:01:55 -0500 Received: from mailrelay1.alcatel.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24328 for ; Fri, 15 Nov 2002 18:59:11 -0500 (EST) From: Axel.Kuttner@alcatel.de Received: from slsas5.stgl.netd.alcatel.de (slsas5.stgl.netd.alcatel.de [149.204.45.57]) by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id BAA23654 for ; Sat, 16 Nov 2002 01:01:46 +0100 (MET) To: nsis@ietf.org Message-ID: Date: Sat, 16 Nov 2002 01:01:43 +0100 X-MIMETrack: Serialize by Router on DEMTA001/DE/ALCATEL(Release 5.0.9 |November 16, 2001) at 11/16/2002 01:01:46 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes Subject: [NSIS] Axel KUTTNER/DE/ALCATEL is out of the office. Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , I will be out of the office starting 15.11.2002 and will not return until 18.11.2002. Thank you for keeping me informed. I will respond to your message when I return. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Nov 16 03:30: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 DAA13241 for ; Sat, 16 Nov 2002 03:30:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAG8WYl25291 for nsis-archive@odin.ietf.org; Sat, 16 Nov 2002 03:32: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 gAG8VFv25260; Sat, 16 Nov 2002 03:31: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 gAG8SEv25198 for ; Sat, 16 Nov 2002 03:28:14 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13191 for ; Sat, 16 Nov 2002 03:25:25 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sat, 16 Nov 2002 08:28:01 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5EC4@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Date: Sat, 16 Nov 2002 08:28:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Subject: [NSIS] terminology top 10 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , dear all, attentive agenda readers will note that i am underpinning claim to be an idiot by volunteering for the terminology slot in the atlanta session. i have gathered a personal 'top ten' issues, where there seems to either a tension about what terms to use or not to use, or where terminology issues may be clouding discussion of a more deep-seated conceptual issue. please suggest additions or deletions (we have 10 minutes). or else, have your linguistic skills finely tuned for tuesday afternoon. i expect to see helpful definitions flooding in via instant messages ;-) [the following is in a deliberately abbreviated format:] nsis (name of a working group, or name of 'what we are doing') path-coupled/decoupled (what do they mean) sender/receiver (how do we use them) initiated/oriented (is it clear what these mean? is there more than one concept?) path-related/unrelated (do we need to introduce and discuss the concepts) peer vs. neighbour discovery? selection? path vs. peer discovery (is there a non controversial use of the word 'discovery'?) ntlp/ntsp (other preferred terms?) reservation identifier? path identifier? (are there two concepts? what are we identifying?) reservation? resource management? (too qos-centric? or should we declare them as abstract?) cheers, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Nov 16 04:40: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 EAA14344 for ; Sat, 16 Nov 2002 04:40:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAG9gJO28744 for nsis-archive@odin.ietf.org; Sat, 16 Nov 2002 04:42:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAG9gGv28737; Sat, 16 Nov 2002 04:42: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 gAG9fov28721 for ; Sat, 16 Nov 2002 04:41:50 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14330 for ; Sat, 16 Nov 2002 04:39:03 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gAG9Xdl19349; Sat, 16 Nov 2002 10:33:39 +0100 Subject: Re: [NSIS] terminology top 10 To: "Hancock, Robert" Cc: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Sat, 16 Nov 2002 10:41:27 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/16/2002 10:41:30 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Robert, Maybe add RMF, inner-RMF, outer-RMF? Sven. "Hancock, Robert" @ietf.org on 16/11/2002 09:28:00 Sent by: nsis-admin@ietf.org To: nsis@ietf.org cc: Subject: [NSIS] terminology top 10 dear all, attentive agenda readers will note that i am underpinning claim to be an idiot by volunteering for the terminology slot in the atlanta session. i have gathered a personal 'top ten' issues, where there seems to either a tension about what terms to use or not to use, or where terminology issues may be clouding discussion of a more deep-seated conceptual issue. please suggest additions or deletions (we have 10 minutes). or else, have your linguistic skills finely tuned for tuesday afternoon. i expect to see helpful definitions flooding in via instant messages ;-) [the following is in a deliberately abbreviated format:] nsis (name of a working group, or name of 'what we are doing') path-coupled/decoupled (what do they mean) sender/receiver (how do we use them) initiated/oriented (is it clear what these mean? is there more than one concept?) path-related/unrelated (do we need to introduce and discuss the concepts) peer vs. neighbour discovery? selection? path vs. peer discovery (is there a non controversial use of the word 'discovery'?) ntlp/ntsp (other preferred terms?) reservation identifier? path identifier? (are there two concepts? what are we identifying?) reservation? resource management? (too qos-centric? or should we declare them as abstract?) cheers, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Nov 16 04:49: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 EAA14468 for ; Sat, 16 Nov 2002 04:49:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAG9q7l28925 for nsis-archive@odin.ietf.org; Sat, 16 Nov 2002 04:52: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 gAG9q5v28917; Sat, 16 Nov 2002 04:52: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 gAG9pZv28898 for ; Sat, 16 Nov 2002 04:51:35 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14458 for ; Sat, 16 Nov 2002 04:48:47 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gAG9hJC20600; Sat, 16 Nov 2002 10:43:19 +0100 Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier To: Bob Braden Cc: braden@ISI.EDU, nsis@ietf.org, brunner@ccrle.nec.de X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Sat, 16 Nov 2002 10:51:05 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/16/2002 10:51:10 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Bob, Please see inline Thanks, Sven. Bob Braden @ietf.org on 15/11/2002 20:36:26 Sent by: nsis-admin@ietf.org To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: braden@ISI.EDU, nsis@ietf.org, brunner@ccrle.nec.de Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier *> If I understand correctly, we are talking about an identifier that is *> independent of IP addresses (they could be the flow id for QoS and should *> go in the NTLP anyway) and cannot be guaranteed to be needed in all Sven, ?? I don't understand your argument for putting a "flow id for QoS" in the NTLP/CSTP. [I am not claiming there is no argument, mind you; depending upon what you mean by "flow id", I might/might not agree.] [Sven] The point that was raised in the framework, I believe, was that it would be useful to carry source and or destination address in NTLP (if they are carried) for address translation purposes. If these are part of the flow identifier they could be carried in NTLP. We were discussing about a reservation identifier for NSLP, therefor my claim was that we could limit that discussion to an IP address independent identifier since the address dependent part would go in NTLP. I am not sure this is correct/useful but that was the idea. *> applications. Given this, I think it would make sense to make it a *> mandatory component of each NSLP specification (I am assuming that the I would argue against *any* mandatory component of NSLP specifications. I think it is vital for future unforeseen applications of our framework that the NSLP level be unrestricted. It's fine to say, "If an NSLP/ULSP needs this functionality, do it this way: ...", but not to mandate its usage by all NSLPs/ULSPs. [Sven] I read in some other message of this or another thread: mandatory to specify, not mandatory to use. I think this applies to this thing as well. It then covers exactly what you say: "if you need it, do it this way". That would make it optional to use, but if used with a unique specification. *> actual user of this id will be NSLP and therefore it would make more sense *> to put it there). Maybe we could foresee a flag in the NTLP to indicate *> that such an object is present? If it is used in by an NSLP/ULSP, the object can be embedded in the SAPU. The "flag" could be embodied in the encoding used for the SAPU, e.g., it might be the presence of a strongly-typed object as in RSVP v1.) [Sven] OK. Sven. Bob Braden *> *> Sven. *> *> *> *> *> *> "Freytsis, Ilya" @ietf.org on 08/11/2002 15:42:46 *> *> Sent by: nsis-admin@ietf.org *> *> *> To: "'Hancock, Robert'" , Bob Braden *> , nsis@ietf.org, brunner@ccrle.nec.de *> cc: *> Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i *> dentifier *> *> *> My comments in-line *> *> Regards, *> Ilya *> *> -----Original Message----- *> From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] *> Sent: Thursday, November 07, 2002 5:37 PM *> To: Bob Braden; nsis@ietf.org; brunner@ccrle.nec.de *> Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i *> dentifier *> *> Hi, *> *> A comment on scope/layering of this reservation identifier thing (if it *> ever *> exists): *> *> > *> So reformulating the requirement into "An NSIS protocol *> > MUST support a *> > *> reservation identifer" would solve the first one. *> > *> > OK, although I would say "MUST be able to support". *> > *> > BTW, a reservation identifier is presumably a multi-hop *> > thing, so in my *> > 2-level model it is a creature of ULSP, i.e., it is carried in an *> > SAPU. That's good, because non-QoS signaling applications probably *> > don't have any reservations to identify. *> *> I think we need to work through this. *> *> 1. As Marcus has said, we are signalling to set up something, and that *> something is what we want to identify to be able to manipulate - it doesn't *> matter if it's QoS (and called a reservation) or something else. *> [IF] That is right to the point. I just want to add that that something is *> separate from the flow but used by the flow. The main value of the *> reservation ID in my mind is to enable referencing that something *> independently from any other characteristics of the flow. *> *> The v6 flow label draft calls this something 'flow state' so this *> identifier *> could be a "flow state id". Would that be a better term? *> [IF] I don't think. See the argument above. *> 2. My feeling is that this XXX-id would be useful for general signalling *> applications (i.e. if you use the signalling application in a mobile *> enviroment, efficiently moving the state is something you want to do *> anyway). Also, providing the facility might be tricky, and might require *> subtle interworking with other protocols (e.g. mobility ones). *> *> In that case, it be better to provide it as a generic service rather than *> solving the problem for each signalling application. *> [IF] Agreed. *> 3. So, wouldn't one want it within the NTLP (lower layer)? *> [IF] Absolutely. *> 4. Or, should we be thinking of some kind of 'core' NSLP toolkit which has *> these generic facilities? *> [IF] I think it is good way to move forward. *> Cheers, *> *> Robert H. *> _______________________________________________ *> nsis mailing list *> nsis@ietf.org *> https://www1.ietf.org/mailman/listinfo/nsis *> _______________________________________________ *> nsis mailing list *> nsis@ietf.org *> https://www1.ietf.org/mailman/listinfo/nsis *> *> *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Nov 17 10:36: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 KAA20024 for ; Sun, 17 Nov 2002 10:36:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAHFcYg23115 for nsis-archive@odin.ietf.org; Sun, 17 Nov 2002 10: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 gAHFcTv23108; Sun, 17 Nov 2002 10:38:29 -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 gAHFZ1v22480 for ; Sun, 17 Nov 2002 10:35:01 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19935 for ; Sun, 17 Nov 2002 10:32:20 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAHFYPO19073 for ; Sun, 17 Nov 2002 17:34:26 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 17 Nov 2002 17:34:13 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 17 Nov 2002 17:34:13 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 17 Nov 2002 17:34:13 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 17 Nov 2002 17:34:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 17 Nov 2002 17:34:12 +0200 Message-ID: Thread-Topic: [NSIS] Detailed comments on draft-ietf-nsis-fw-01.txt Thread-Index: AcKMH77a4Jf3lcjpT2SIjs2vWsKnNQCLugOw X-Priority: 1 Priority: Urgent Importance: high To: X-OriginalArrivalTime: 17 Nov 2002 15:34:12.0748 (UTC) FILETIME=[C79F14C0:01C28E4E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAHFZ1v22481 Subject: [NSIS] Presenters at IETF 55 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, For those who have slidesets schedules for discussion at IETF 55, please send your slidesets to me as soon as possible. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Nov 17 11: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 LAA20945 for ; Sun, 17 Nov 2002 11:24:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAHGR7K24820 for nsis-archive@odin.ietf.org; Sun, 17 Nov 2002 11:27: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 gAHGR4v24789; Sun, 17 Nov 2002 11:27: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 gAHGLov24660 for ; Sun, 17 Nov 2002 11:21:50 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20804 for ; Sun, 17 Nov 2002 11:19:08 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAHGLEO27778 for ; Sun, 17 Nov 2002 18:21:14 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 17 Nov 2002 18:21:45 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 17 Nov 2002 18:21:45 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 17 Nov 2002 18:21:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 17 Nov 2002 18:21:44 +0200 Message-ID: Thread-Topic: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier Thread-Index: AcKNVdUeD6Vw6dBVSxap3KW9Rpn1LQA/NV5g To: X-OriginalArrivalTime: 17 Nov 2002 16:21:45.0066 (UTC) FILETIME=[6BBC44A0:01C28E55] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAHGLov24661 Subject: [NSIS] NSIS WG IETF 55 Page Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, Trying to get organized for IETF 55, I have a webpage setup with the agenda, links to drafts & presentations. The initial version can be found here: http://www-nrc.nokia.com/sua/nsis/ietf55/index.htm Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Nov 17 13:01: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 NAA22490 for ; Sun, 17 Nov 2002 13:01:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAHI3Wc29117 for nsis-archive@odin.ietf.org; Sun, 17 Nov 2002 13:03: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 gAHI3Sv29110; Sun, 17 Nov 2002 13:03: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 gAHI2kv29093 for ; Sun, 17 Nov 2002 13:02:46 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22474 for ; Sun, 17 Nov 2002 13:00:04 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAHI3PB12307 for ; Sun, 17 Nov 2002 20:03:25 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 17 Nov 2002 20:02:18 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 17 Nov 2002 20:02:17 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 17 Nov 2002 20:02:17 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 17 Nov 2002 20:02:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt Date: Sun, 17 Nov 2002 20:02:16 +0200 Message-ID: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt Thread-Index: AcKMpSskgrIFDAX6RPOfylF3mja3nwBvYaUQ To: Cc: X-OriginalArrivalTime: 17 Nov 2002 18:02:16.0927 (UTC) FILETIME=[770136F0:01C28E63] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAHI2kv29094 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Vlora, > 2. I find it a very good idea to include protocols developed outside > IETF, but the list in the draft can be extended. So in your question > on adding more protocols apart from YESSIR, Boomerang, I suggest that > you add other lightweight signalling protocols such as: > > - Resource Management in Diffserv On DemAnd (RODA) PHR > http://www.ietf.org/internet-drafts/draft-westberg-rmd-od-phr-02.txt > see also PfHSN2002, Networking2002, ISCC 2002 proceedings,etc. > > - Resource Management in Diffserv Measurement-based Admission Control PHR > http://www.ietf.org/internet-drafts/draft-westberg-rmd-mbac-phr-00.txt > > I will be happy to provide you with some input on these protocols. Do you have any code for these where folks could test them out? If you have any simulation results, etc. it would be great to get info on them. > -Section 5.5 > You focus on the signalling protocols and yet you have explained > the ITSUMO framework. Is the idea here to include > framework/architectures as well? I would hope we would not focus on framework or architectures as these are somewhat tangential to our purpose. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Nov 17 13:57: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 NAA23391 for ; Sun, 17 Nov 2002 13:57:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAHJ09K31379 for nsis-archive@odin.ietf.org; Sun, 17 Nov 2002 14:00:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAHJ07v31370; Sun, 17 Nov 2002 14:00: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 gAHIuiv31255 for ; Sun, 17 Nov 2002 13:56:44 -0500 Received: from porsta.cs.Helsinki.FI (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23323 for ; Sun, 17 Nov 2002 13:54:03 -0500 (EST) Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id gAHIucC16601 for ; Sun, 17 Nov 2002 20:56:39 +0200 Date: Sun, 17 Nov 2002 20:56:38 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt In-Reply-To: <2B06CD3FC17AF64587BC7A7617B230C022BD12@enleent103.nl.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi, thank you for the comments. Below some answers: Jukka On Fri, 15 Nov 2002, Vlora Rexhepi (ELN) wrote: > Hi, > > I have gone through the analysis draft and I have > some questions/comments on it... > > In general: > 1. The draft provides a good collection of references to > extensions of RSVP. These are mentioned very briefly, however > some of the RFC need to be explained more extensively than > others such as [RFC3175], [RFC3209]. For this you could use the > text from the: > http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-03.txt True, although it would would be good not to include too much description about all extensions, but rather give the review of the extension - the reader can find out more information from the reference. I fear the document will be horribly long otherwise... > > 2. I find it a very good idea to include protocols developed outside > IETF, but the list in the draft can be extended. So in your question > on adding more protocols apart from YESSIR, Boomerang, I suggest that > you add other lightweight signalling protocols such as: > - Resource Management in Diffserv On DemAnd (RODA) PHR > http://www.ietf.org/internet-drafts/draft-westberg-rmd-od-phr-02.txt > see also PfHSN2002, Networking2002, ISCC 2002 proceedings,etc. > Could you provide more detailed references? Which articles? Title, authors? > - Resource Management in Diffserv Measurement-based Admission Control PHR > http://www.ietf.org/internet-drafts/draft-westberg-rmd-mbac-phr-00.txt > > I will be happy to provide you with some input on these protocols. > > 3. The draft tends to be an "review of existing protocols". > However the review itself is based on several common issues such as > Processing Overhead, Bandwidth Consumption, etc. I suggest that these > be clearly defined and use a common terminology. > > Specifically: > - Section 2.3 > It is not clear whether in this section you explain processing overhead > due to signalling or scalability in terms of number of reservation states. > I consider these two as separate issues. As I see it, the processing of signalling is one thing and the scalability is tied to the hardware of the router you are evaluating. Thus, evaluating the processing overhead is more generic. Still, we should try to avoid the words "scalability, scalable". > In the same section RSVP aggregation is explained. I believe they > should be explained separately. > Also the following paragraph is rather contradictory: > " > Still, for example, the implementation of the daemon can have a huge > effect on the scalability. In [KaSh01], the authors show that their > RSVP daemon is able to handle much more flows than the de-facto ISI > RSVP daemon implementation. Furthermore, the scalability concern > commonly associated with RSVP are more or less subject to > individual's views on what "scalability" is. > " > as initially you say that the daemon implementation can impact > scalability and than you continue by saying that "scalability" is > subjective to the individual's understanding of it?! yes, true, I shouldn't have used the word scalability. Something along the processing needed to support n number of flow states - whether the number of flows supported is high or low depends on the individuals view and requirements. I tried to say two different things in one paragraph...:) > > - Section 2.4 > Considering the size of signalling messages the Bandwidth Consumption > does not seem to be important, unless we're talking about wireless > links. What was the motivation for having it there? > Exactly that: how much bandwidth does the signalling consume, both initially and to keep the reservation/resources reserved. I don't see how bandwidth utilization is only related to wireless networks, though. I think this is an issue, perhaps not the most important for wired networks... but, the wireless ...:) > -Section 2.7 > you mention "killer problems", I assume you meant killer reservation > problems... You lost me...:) The point of this section was to discuss how well (or not) a protocol could be deployed in different networks, and give some examples of work done in the area. > > - Section 3.4 and section 4.4 > The issues of the reservation identifier and the refresh of the > reservation state are common for the signalling protocols RSVP, YESSIR > and Boomerang when considering mobility support. > However in case of YESSIR and Boomerang the refresh of the reservation > state is different than in RSVP as both YESSIR and Boomerang are > sender initiated, which means that there is no need to store backward > routing information. I would suggest that in Section 3.4, Section 4.4 > this is explained, instead of just referring to Section 2.5. True. The evaluation of all protocols is still in a very early stage, especially regarding YESSIR, Boomerang, Insignia, ... > > -Section 5.5 > You focus on the signalling protocols and yet you have explained > the ITSUMO framework. Is the idea here to include framework/architectures > as well? This was probably a mistake. Still, ITSUMO is an example of a bandwidth broker (off-path signalling?) scheme, so I thought it could be there. On the other hand, there is not much to evaluate from a protocol POV. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 18 07:12: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 HAA18746 for ; Mon, 18 Nov 2002 07:12:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAICEUw19292 for nsis-archive@odin.ietf.org; Mon, 18 Nov 2002 07: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 gAICESv19284; Mon, 18 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 gAICB7v19216 for ; Mon, 18 Nov 2002 07:11:07 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18654 for ; Mon, 18 Nov 2002 07:08:28 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAICAuQ1006636; Mon, 18 Nov 2002 13:10:56 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WWL2YZDG; Mon, 18 Nov 2002 13:10:56 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Nov 2002 13:10:56 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C022BD18@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: d147e7c8 ca231590 df17dee1 00000138 From: "Vlora Rexhepi (ELN)" To: "'john.loughney@nokia.com'" Cc: nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt Date: Mon, 18 Nov 2002 13:10:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAICB7v19217 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi John, |> 2. I find it a very good idea to include protocols developed outside |> IETF, but the list in the draft can be extended. So in your question |> on adding more protocols apart from YESSIR, Boomerang, I |suggest that |> you add other lightweight signalling protocols such as: |> |> - Resource Management in Diffserv On DemAnd (RODA) PHR |> http://www.ietf.org/internet-drafts/draft-westberg-rmd-od-phr-02.txt |> see also PfHSN2002, Networking2002, ISCC 2002 proceedings,etc. |> |> - Resource Management in Diffserv Measurement-based |Admission Control PHR |> |http://www.ietf.org/internet-drafts/draft-westberg-rmd-mbac-phr-00.txt |> |> I will be happy to provide you with some input on these protocols. | |Do you have any code for these where folks could test them out? If |you have any simulation results, etc. it would be great to get info |on them. | There is a prototype implementation in Linux of both protocols (RODA and RIMA) and also a lot of simulation results (mainly on RODA). Some of the results on the RODA as I mentioned are already presented in conferences. The most recent ones are: 1. Westberg, et. al., "Resource Management in Diffserv (RMD): A Functionality and Performance Behavior Overview", PfHSN 2002 proceedings, Berlin. 2. Czászár, et. al. "Severe Congestion Handling with Resource Management On Demand ", Networking2002 proceedings, Pisa, Italy. 3. Jacobsson, et.al. "Resource Management in Differentiated Services: A Prototype Implementation". 7th IEEE SCC 2002 proceedings, Italy. And as we're continuously working on the protocols there hasn't been any release of the code yet. |> -Section 5.5 |> You focus on the signalling protocols and yet you have explained |> the ITSUMO framework. Is the idea here to include |> framework/architectures as well? | |I would hope we would not focus on framework or architectures |as these are |somewhat tangential to our purpose. Agreed. Regards, Vlora _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 18 08:01: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 IAA19780 for ; Mon, 18 Nov 2002 08:01:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAID39C21456 for nsis-archive@odin.ietf.org; Mon, 18 Nov 2002 08:03:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAID36v21448; Mon, 18 Nov 2002 08:03: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 gAID2Jv21420 for ; Mon, 18 Nov 2002 08:02:19 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19756 for ; Mon, 18 Nov 2002 07:59:40 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAID2GQ1022694; Mon, 18 Nov 2002 14:02:16 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id W5PL9XQK; Mon, 18 Nov 2002 14:02:16 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Nov 2002 14:02:16 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C022BD19@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: cfcdf074 ca231590 df17dee1 00000138 From: "Vlora Rexhepi (ELN)" To: "'Jukka MJ Manner'" , nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt Date: Mon, 18 Nov 2002 14:02:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAID2Kv21421 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Jukka, |> In general: |> 1. The draft provides a good collection of references to |> extensions of RSVP. These are mentioned very briefly, however |> some of the RFC need to be explained more extensively than |> others such as [RFC3175], [RFC3209]. For this you could use the |> text from the: |> |http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis- |03.txt | |True, although it would would be good not to include too much |description |about all extensions, but rather give the review of the extension - the |reader can find out more information from the reference. I fear the |document will be horribly long otherwise... | I agree with you. However I think that RSVP Aggregation and RSVP-TE should be discussed in more detail. |> 2. I find it a very good idea to include protocols developed outside |> IETF, but the list in the draft can be extended. So in your question |> on adding more protocols apart from YESSIR, Boomerang, I |suggest that |> you add other lightweight signalling protocols such as: |> - Resource Management in Diffserv On DemAnd (RODA) PHR |> http://www.ietf.org/internet-drafts/draft-westberg-rmd-od-phr-02.txt |> see also PfHSN2002, Networking2002, ISCC 2002 proceedings,etc. |> | |Could you provide more detailed references? Which articles? Title, |authors? I already replied to John's question on this. Here are some recent papers: 1. Westberg, et. al., "Resource Management in Diffserv (RMD): A Functionality and Performance Behavior Overview", PfHSN 2002 proceedings, Berlin. 2. Czászár, et. al. "Severe Congestion Handling with Resource Management On Demand ", Networking2002 proceedings, Pisa, Italy. 3. Jacobsson, et.al. "Resource Management in Differentiated Services: A Prototype Implementation". 7th IEEE SCC 2002 proceedings, Italy. |As I see it, the processing of signalling is one thing and the |scalability |is tied to the hardware of the router you are evaluating. Thus, |evaluating the processing overhead is more generic. Still, we |should try |to avoid the words "scalability, scalable". Why should we avoid it? If there is a well defined and agreed terminology we could still use it. You will need to define 'Processing Overhead' just the same. I think 'Scalability' (in terms of number of states, number of hand-offs, etc) is an important performance issue for the IP QoS protocols and it should not be avoided. |> In the same section RSVP aggregation is explained. I believe they |> should be explained separately. |> Also the following paragraph is rather contradictory: |> " |> Still, for example, the implementation of the daemon can have a huge |> effect on the scalability. In [KaSh01], the authors show that their |> RSVP daemon is able to handle much more flows than the de-facto ISI |> RSVP daemon implementation. Furthermore, the scalability concern |> commonly associated with RSVP are more or less subject to |> individual's views on what "scalability" is. |> " |> as initially you say that the daemon implementation can impact |> scalability and than you continue by saying that "scalability" is |> subjective to the individual's understanding of it?! | |yes, true, I shouldn't have used the word scalability. |Something along the |processing needed to support n number of flow states - whether |the number |of flows supported is high or low depends on the individuals view and |requirements. I tried to say two different things in one |paragraph...:) the paragraph does talk about scalability :), which is good, but I think it's better if you remove completely the text related to 'individuals view'. repeating myself :), a good terminology/definition section will be helpful here. |> - Section 2.4 |> Considering the size of signalling messages the Bandwidth |Consumption |> does not seem to be important, unless we're talking about wireless |> links. What was the motivation for having it there? |> | |Exactly that: how much bandwidth does the signalling consume, both |initially and to keep the reservation/resources reserved. I |don't see how |bandwidth utilization is only related to wireless networks, though. I |think this is an issue, perhaps not the most important for wired |networks... but, the wireless ...:) Ok I see your point. |> -Section 2.7 |> you mention "killer problems", I assume you meant killer reservation |> problems... | |You lost me...:) The point of this section was to discuss how well (or |not) a protocol could be deployed in different networks, and give some |examples of work done in the area. this was more of an editorial comment to change "killer problems" into "killer reservation problems" :). |> - Section 3.4 and section 4.4 |> The issues of the reservation identifier and the refresh of the |> reservation state are common for the signalling protocols |RSVP, YESSIR |> and Boomerang when considering mobility support. |> However in case of YESSIR and Boomerang the refresh of the |reservation |> state is different than in RSVP as both YESSIR and Boomerang are |> sender initiated, which means that there is no need to store |backward |> routing information. I would suggest that in Section 3.4, |Section 4.4 |> this is explained, instead of just referring to Section 2.5. | |True. The evaluation of all protocols is still in a very early stage, |especially regarding YESSIR, Boomerang, Insignia, ... | Well if you need input on these and others I would gladly help. |> -Section 5.5 |> You focus on the signalling protocols and yet you have explained |> the ITSUMO framework. Is the idea here to include |framework/architectures |> as well? | |This was probably a mistake. Still, ITSUMO is an example of a |bandwidth |broker (off-path signalling?) scheme, so I thought it could be |there. On |the other hand, there is not much to evaluate from a protocol POV. I agree with you. Although interesting I do not think ITSUMO framework fits in this draft. Regards, Vlora _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 18 09:36: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 JAA22052 for ; Mon, 18 Nov 2002 09:36:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIEcP728045 for nsis-archive@odin.ietf.org; Mon, 18 Nov 2002 09:38: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 gAIEcHv28036; Mon, 18 Nov 2002 09:38: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 gAIEbbv28005 for ; Mon, 18 Nov 2002 09:37:37 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22011 for ; Mon, 18 Nov 2002 09:34:56 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAIEb1O06032 for ; Mon, 18 Nov 2002 16:37:01 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 18 Nov 2002 16:37:33 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 18 Nov 2002 16:37:33 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 18 Nov 2002 16:37:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt Date: Mon, 18 Nov 2002 16:37:32 +0200 Message-ID: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt Thread-Index: AcKO+54jo2tLQOtGQ4S5dFhxn3UCQAAFEXTA To: Cc: X-OriginalArrivalTime: 18 Nov 2002 14:37:32.0803 (UTC) FILETIME=[07826530:01C28F10] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAIEbbv28006 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Vlora, > |Do you have any code for these where folks could test them out? If > |you have any simulation results, etc. it would be great to get info > |on them. > | > > There is a prototype implementation in Linux of both protocols (RODA and RIMA) > and also a lot of simulation results (mainly on RODA). Some of the results on > the RODA as I mentioned are already presented in conference. The most recent > ones are: > > 1. Westberg, et. al., "Resource Management in Diffserv (RMD): > A Functionality > and Performance Behavior Overview", PfHSN 2002 proceedings, Berlin. > > 2. Czászár, et. al. "Severe Congestion Handling with Resource > Management On Demand ", Networking2002 proceedings, Pisa, Italy. > > 3. Jacobsson, et.al. "Resource Management in Differentiated > Services: A Prototype Implementation". 7th IEEE SCC 2002 > proceedings, Italy. Any chance of weblinks for these, just to make my life easier. Anyhow, thanks for the references. > And as we're continuously working on the protocols there hasn't been > any release of the code yet. No problem. > |> -Section 5.5 > |> You focus on the signalling protocols and yet you have explained > |> the ITSUMO framework. Is the idea here to include > |> framework/architectures as well? > | > |I would hope we would not focus on framework or architectures > |as these are somewhat tangential to our purpose. > Agreed. Good. thanks for the comments, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 18 10:11: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 KAA23040 for ; Mon, 18 Nov 2002 10:11:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIFDFm30055 for nsis-archive@odin.ietf.org; Mon, 18 Nov 2002 10:13:15 -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 gAIFDBv30038; Mon, 18 Nov 2002 10:13: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 gAIFCov30006 for ; Mon, 18 Nov 2002 10:12:50 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23007 for ; Mon, 18 Nov 2002 10:10:09 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAIFCjQ1004889; Mon, 18 Nov 2002 16:12:45 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WWLHCX4Q; Mon, 18 Nov 2002 16:12:45 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Nov 2002 16:12:45 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C022BD1C@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: e54edd69 ca231590 df17dee1 00000138 From: "Vlora Rexhepi (ELN)" To: "'john.loughney@nokia.com'" Cc: nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-00.txt Date: Mon, 18 Nov 2002 16:12:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi John, |Any chance of weblinks for these, just to make my life easier. Anyhow, |thanks for the references. | I'm afraid you'll have to check the proceedings as there are no weblinks to full papers. Regards, Vlora _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 18 14:32: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 OAA01051 for ; Mon, 18 Nov 2002 14:32:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIJYUD13403 for nsis-archive@odin.ietf.org; Mon, 18 Nov 2002 14:34: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 gAIJYQv13396; Mon, 18 Nov 2002 14:34: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 gAIJXTv13345 for ; Mon, 18 Nov 2002 14:33:29 -0500 Received: from cms1.etri.re.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01002 for ; Mon, 18 Nov 2002 14:30:47 -0500 (EST) From: yhwkim@etri.re.kr Received: by cms1.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Nov 2002 04:25:48 +0900 Message-ID: <54A1DDB4ACD5D511B0F900D0B7A8DC08A75D52@cms1.etri.re.kr> To: nsis@ietf.org Date: Tue, 19 Nov 2002 04:25:47 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28F38.4BFABFA0" Subject: [NSIS] To nsis members Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling 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_01C28F38.4BFABFA0 Content-Type: text/plain; charset="euc-kr" Hi, nsis members, In this meeting, I brought a contribution. I tried to introduce this contribution in the ccamp WG, I failed it. I think this contribution is also related to your WG as well. If you grant the presentation admission to me, of course, under the assumption that there is a time-slot for me, I will introduce this contribution in your WG. My contribution is the draft-kim-ccamp-cc-protection-00.txt with the title of "Requirements of Control Channels Protection Protocol in GMPLS". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kim-ccamp-cc-protection-00.txt Although I have not get a chance to introduce my contribution, I want to discuss this item through the maling list. I have sent this email to you after getting a advice from the nsis chair. ****************************************** Young Hwa Kim Senior Member, Network Technology Lab., ETRI Office No. : 82-42-860-5819 Fax No. : 82-42-860-6342 Mobile No. : 011-433-5819 Email addr. : yhwkim@etri.re.kr ****************************************** ------_=_NextPart_001_01C28F38.4BFABFA0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable To nsis members

Hi, nsis members,

In this meeting, I brought a contribution.
I tried to introduce this contribution in the ccamp = WG, I failed it.
I think this contribution is also related to your WG = as well.
If you grant the presentation admission to me, of = course, under the assumption that there is a time-slot for me,
I will introduce this contribution in your = WG.

My contribution is the = draft-kim-ccamp-cc-protection-00.txt
with the title of "Requirements of Control = Channels Protection Protocol in GMPLS".

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kim-ccamp-cc= -protection-00.txt

Although I have not get a chance to introduce my = contribution, I want to discuss this item through the maling = list.

I have sent this email to you after getting a advice = from the nsis chair.

******************************************
Young Hwa Kim
Senior Member, Network Technology Lab., ETRI
Office No. : 82-42-860-5819
Fax No. : 82-42-860-6342
Mobile No. : 011-433-5819
Email addr. : yhwkim@etri.re.kr
******************************************

------_=_NextPart_001_01C28F38.4BFABFA0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 18 15:51: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 PAA03064 for ; Mon, 18 Nov 2002 15:51:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAIKrNI18214 for nsis-archive@odin.ietf.org; Mon, 18 Nov 2002 15:53:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIKrJv18205; Mon, 18 Nov 2002 15: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 gAIKnjv17995 for ; Mon, 18 Nov 2002 15:49:45 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02955 for ; Mon, 18 Nov 2002 15:47:01 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAIKn4O14268 for ; Mon, 18 Nov 2002 22:49:04 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 18 Nov 2002 22:49:36 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 18 Nov 2002 22:49:35 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 18 Nov 2002 22:49:35 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 18 Nov 2002 22:49:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: [NSIS] To nsis members Date: Mon, 18 Nov 2002 22:49:34 +0200 Message-ID: Thread-Topic: [NSIS] To nsis members Thread-Index: AcKPOYynGBsxZUFITPuDcW5l1EB/0wAChOeQ To: , X-OriginalArrivalTime: 18 Nov 2002 20:49:34.0836 (UTC) FILETIME=[007A5340:01C28F44] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAIKnjv17996 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, > In this meeting, I brought a contribution. > I tried to introduce this contribution in the ccamp WG, I failed it. > I think this contribution is also related to your WG as well. > If you grant the presentation admission to me, of course, under the assumption > that there is a time-slot for me, I will introduce this contribution in your WG. > My contribution is the draft-kim-ccamp-cc-protection-00.txt > with the title of "Requirements of Control Channels Protection Protocol in GMPLS". > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kim-ccamp-cc-protection-00.txt > Although I have not get a chance to introduce my contribution, I want to discuss > this item through the maling list. I have sent this email to you after getting a > advice from the nsis chair. As I have mentioned, we have no time in this meeting for any addtional presentations. As this draft has had no discussion in the NSIS WG, it would be inappropriate to discuss it during the IETF meeting. However, if you feel it is of interest to this working working, could you please explain why? I have read the draft & I don't see how it could be relevant to NSIS. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 18 16:38: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 QAA04364 for ; Mon, 18 Nov 2002 16:38:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAILeOc21400 for nsis-archive@odin.ietf.org; Mon, 18 Nov 2002 16:40: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 gAILeKv21390; Mon, 18 Nov 2002 16:40: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 gAILdKv21327 for ; Mon, 18 Nov 2002 16:39:20 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04309 for ; Mon, 18 Nov 2002 16:36:36 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAILe1B28788 for ; Mon, 18 Nov 2002 23:40:01 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 18 Nov 2002 23:39:13 +0200 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 18 Nov 2002 23:39:13 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 18 Nov 2002 23:39:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 18 Nov 2002 23:39:12 +0200 Message-ID: Thread-Topic: [Tsvwg] IETF 55 TSVWG Agenda Thread-Index: AcKPR1Nruh9e1UvLRL2Tod0N++yJkAANzFzg To: X-OriginalArrivalTime: 18 Nov 2002 21:39:13.0299 (UTC) FILETIME=[EFC7B630:01C28F4A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAILdKv21330 Subject: [NSIS] Offpath signaling discussion at the TSVWG Meeting (FW: [Tsvwg] IETF 55 TSVWG Agenda) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, There will be a discussion about off-of-path signaling on Tuesday. If interested, I suggest you attend. John -----Original Message----- From: ext Allison Mankin [mailto:mankin@psg.com] Sent: 18 November, 2002 23:07 To: tsvwg@ietf.org Cc: mankin@psg.com; sob@harvard.edu Subject: [Tsvwg] IETF 55 TSVWG Agenda Folks, Here is our special just-in-time TSVWG agenda! (originally sent Sunday, but it didn't get out, it seems). Tue Afternoon III (15:45-16:45) Transport Area Roundup - Scott and Allison - 30 mins SACK/DSACK - Mark Allman - 15 mins Reading: draft-allman-tcp-sack-13.txt draft-blanton-dsack-use-02.txt Out-of-path signaling - 15 mins Towards a BOF in San Francisco, TBA Tue Afternoon IV (1700-1800) TCP MIB extension - Matt Mathis - 15 mins Issues: Any major functional area uncovered? Comment now! Reading: draft-ietf-tsvwg-tcp-mib-extension-02.txt Eifel - 10 mins - Reiner Ludwig Issue: Publish as Experimental? Reading: draft-ietf-tsvwg-tcp-eifel-response-01.txt F-RTO - 10 mins - Pasi Sarolahti Reading: draft-sarolahti-tsvwg-tcp-frto-02.txt Framing topics - Discussion by authors - 25 mins Reading: draft-culley-iwarp-mpa-01.txt draft-williams-iwarp-ift-00.txt - ------- End of Forwarded Message ------- End of Forwarded Message _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Nov 18 19:13: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 TAA08465 for ; Mon, 18 Nov 2002 19:13:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJ0FZ230210 for nsis-archive@odin.ietf.org; Mon, 18 Nov 2002 19:15: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 gAJ0FWv30171; Mon, 18 Nov 2002 19:15: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 gAJ04ev29021 for ; Mon, 18 Nov 2002 19:04:40 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08057 for ; Mon, 18 Nov 2002 19:01:55 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAJ040O23309 for ; Tue, 19 Nov 2002 02:04:00 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 19 Nov 2002 02:04:30 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Nov 2002 02:04:30 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Nov 2002 02:04:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Date: Tue, 19 Nov 2002 02:04:29 +0200 Message-ID: Thread-Topic: [NSIS] terminology top 10 Thread-Index: AcKNSrRYb+AOcwmlR7+hCQu8THViWwB2T0EA To: X-OriginalArrivalTime: 19 Nov 2002 00:04:30.0300 (UTC) FILETIME=[3B8481C0:01C28F5F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAJ04ev29022 Subject: [NSIS] Updated NSIS IETF 55 page Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, I have been continuously updating the webpage for NSIS WG meeting here at IETF55. The page can be found here: http://www-nrc.nokia.com/sua/nsis/ietf55/index.htm br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 19 14:46: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 OAA14515 for ; Tue, 19 Nov 2002 14:46:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJJmlN09545 for nsis-archive@odin.ietf.org; Tue, 19 Nov 2002 14:48: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 gAJJmev09535; Tue, 19 Nov 2002 14:48: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 gAJJhHv09294 for ; Tue, 19 Nov 2002 14:43:17 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14393 for ; Tue, 19 Nov 2002 14:40:33 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAJJhvB21944 for ; Tue, 19 Nov 2002 21:43:58 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 19 Nov 2002 21:43:09 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Nov 2002 21:43:09 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Nov 2002 21:43:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 19 Nov 2002 21:43:09 +0200 Message-ID: Thread-Topic: [Tsvwg] IETF 55 TSVWG Agenda Thread-Index: AcKPR1Nruh9e1UvLRL2Tod0N++yJkAANzFzgACFJGvA= To: X-OriginalArrivalTime: 19 Nov 2002 19:43:09.0393 (UTC) FILETIME=[E361BC10:01C29003] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAJJhHv09295 Subject: [NSIS] Updated Charter Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, Here is the updated charter I presented at IETF55 today. Please send comments. John Next Steps in Signaling (nsis) Charter Chair(s): J. Loughney Transport Area Director(s): S. Bradner A. Mankin Transport Area Advisor: A. Mankin Mailing Lists: General Discussion: nsis@ietf.org To Subscribe: nsis-request@ietf.org In Body: (un)subscribe Archive: www.ietf.org/mail-archive/working-groups/nsis/current/maillist.html Description of Working Group: The Next Steps in Signaling Working Group is responsible for standardizing an IP signaling protocol with QoS signaling as the use case for NSIS. This working group will concentrate on a two-layer signaling paradigm. The intention is to re-use, where appropriate, the protocol mechanisms of RSVP, while at the same time simplifying it and applying a more general signaling model. The existing work on the requirements, the framework and analysis of existing protocols will be completed and used as input for the protocol work. NSIS will develop a transport layer signaling protocol for the transport of upper layer signaling. In order to support a tool box or building block approach, the two-layer model will be used to seperate the transport of the signaling from the application signaling. This allows for a more general signaling protocol to be developed to support signaling for different services or resources, such as NAT & firewall traversal and QoS resources. The initial NSIs application layer will be an optimzed RSVP signaling. Potential for a second NSIS application layer, in order to ensure a generic transport signaling protocol, will be considered in consultation with the Transport Area directors. Security is a very important concern for NSIS. The working group will study and analyze the threats and security requirements for signaling. Compatibility with authentication and authorization mechanisms such as those of Diameter, COPS-PR, and RSVP-PR auth-session, will be addressed. It is a non-goal of the working group to develop new resource allocation protocols. Resource reservation and traffic engineering are out of scope of this working group. Additionally, third party signaling is out of scope of this working group. Mobility protocols and AAA work are out of scope of the working group. The work produced in this Working Group should work with existing IETF mobility and AAA protocols, including (but not limited to) Mobile IP, SeaMoby Context also welcomes participation and expression of requirements from non-IETF standards organization members, for instance 3GPP, 3GPP2 and ITU-T. Goals and Milestones: JAN 03 Submit "Requirements for Signaling Protocols" to IESG for publication as Informational RFC MAR 03 Submit "RSVP Security Properties" to IESG as Informational RFC APR 03 Submit "NSIS Threats" to IESG as Informational RFC JUN 03 Submit "Analysis of Existing Signaling Protocols" to IESG as Informational RFC AUG 03 Submit "Next Steps in Signaling: Framework" to IESG for publication as Informational RFC MAR 04 Submit "NSIS Transport Protocol" to IESG for publication for Proposed Standard MAR 04 Submit "NSIS QoS Application Protocol" to IESG for publication for Proposed Standard _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 19 16:52: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 QAA18006 for ; Tue, 19 Nov 2002 16:52:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJLse317523 for nsis-archive@odin.ietf.org; Tue, 19 Nov 2002 16:54: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 gAJLsYv17490; Tue, 19 Nov 2002 16:54: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 gAJLlDv17209 for ; Tue, 19 Nov 2002 16:47:13 -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 QAA17707 for ; Tue, 19 Nov 2002 16:44:28 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gAJLkrsA017893; Tue, 19 Nov 2002 13:46:53 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAQ59819; Tue, 19 Nov 2002 13:41:27 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA17135; Tue, 19 Nov 2002 13:47:05 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15834.45401.169953.85789@thomasm-u1.cisco.com> Date: Tue, 19 Nov 2002 13:47:05 -0800 (PST) To: john.loughney@nokia.com Cc: Subject: [NSIS] Updated Charter In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit So I'm somewhat confused about the earlier exchange today about whether signaling to alter the route packets take is in or out of scope, but if it's in, it seems really odd to leave such a large deliverable out of the charter. As in, I'd imagine that a lot of the routing area folks would probably be highly interested in such a thing, and it wouldn't be very obvious that it was happening here. Mike john.loughney@nokia.com writes: > Hi all, > > Here is the updated charter I presented at IETF55 today. Please send comments. > > John > > Next Steps in Signaling (nsis) Charter > > Chair(s): > J. Loughney > > Transport Area Director(s): > S. Bradner > A. Mankin > > Transport Area Advisor: > A. Mankin > > Mailing Lists: > General Discussion: nsis@ietf.org > To Subscribe: nsis-request@ietf.org > In Body: (un)subscribe > Archive: www.ietf.org/mail-archive/working-groups/nsis/current/maillist.html > > Description of Working Group: > > The Next Steps in Signaling Working Group is responsible for standardizing an IP signaling protocol with QoS signaling as the use case for NSIS. This working group will concentrate on a two-layer signaling paradigm. The intention is to re-use, where appropriate, the protocol mechanisms of RSVP, while at the same time simplifying it and applying a more general signaling model. > > The existing work on the requirements, the framework and analysis of existing protocols will be completed and used as input for the protocol work. > > NSIS will develop a transport layer signaling protocol for the transport of upper layer signaling. In order to support a tool box or building block approach, the two-layer model will be used to seperate the transport of the signaling from the application signaling. This allows for a more general signaling protocol to be developed to support signaling for different services or resources, such as NAT & firewall traversal and QoS resources. The initial NSIs application layer will be an optimzed RSVP signaling. Potential for a second NSIS application layer, in order to ensure a generic transport signaling protocol, will be considered in consultation with the Transport Area directors. > > Security is a very important concern for NSIS. The working group will study and analyze the threats and security requirements for signaling. Compatibility with authentication and authorization mechanisms such as those of Diameter, COPS-PR, and RSVP-PR auth-session, will be addressed. > > It is a non-goal of the working group to develop new resource allocation protocols. Resource reservation and traffic engineering are out of scope of this working group. Additionally, third party signaling is out of scope of this working group. Mobility protocols and AAA work are out of scope of the working group. The work produced in this Working Group should work with existing IETF mobility and AAA protocols, including (but not limited to) Mobile IP, SeaMoby Context also welcomes participation and expression of requirements from non-IETF standards organization members, for instance 3GPP, 3GPP2 and ITU-T. > > Goals and Milestones: > > JAN 03 Submit "Requirements for Signaling Protocols" to IESG for publication as Informational RFC > MAR 03 Submit "RSVP Security Properties" to IESG as Informational RFC > APR 03 Submit "NSIS Threats" to IESG as Informational RFC > JUN 03 Submit "Analysis of Existing Signaling Protocols" to IESG as Informational RFC > AUG 03 Submit "Next Steps in Signaling: Framework" to IESG for publication as Informational RFC > MAR 04 Submit "NSIS Transport Protocol" to IESG for publication for Proposed Standard > MAR 04 Submit "NSIS QoS Application Protocol" to IESG for publication for Proposed Standard > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 19 16:56: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 QAA18165 for ; Tue, 19 Nov 2002 16:56:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJLwkk17781 for nsis-archive@odin.ietf.org; Tue, 19 Nov 2002 16:58: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 gAJLwiv17742; Tue, 19 Nov 2002 16:58: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 gAJLrAv17421 for ; Tue, 19 Nov 2002 16:53:10 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17933 for ; Tue, 19 Nov 2002 16:50:25 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAJLqVO00592 for ; Tue, 19 Nov 2002 23:52:31 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Nov 2002 23:52:24 +0200 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Nov 2002 23:52:23 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Nov 2002 23:52:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Updated Charter Date: Tue, 19 Nov 2002 23:52:21 +0200 Message-ID: Thread-Topic: [NSIS] Updated Charter Thread-Index: AcKQFTcHAuq+6/01Tle9kBXUwNTMwQAAF8Xw To: Cc: X-OriginalArrivalTime: 19 Nov 2002 21:52:22.0716 (UTC) FILETIME=[F0B8EFC0:01C29015] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAJLrAv17422 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Michael, > So I'm somewhat confused about the earlier > exchange today about whether signaling to alter > the route packets take is in or out of scope, but > if it's in, it seems really odd to leave such a > large deliverable out of the charter. As in, I'd > imagine that a lot of the routing area folks would > probably be highly interested in such a thing, and > it wouldn't be very obvious that it was happening > here. So, I would prefer not to affect routing - any more than what RSVP currently does. I'm not a routing expert, so I worry that this would be a big can of worms. However, what does the WG think about this? Do you have an opinion on what would be the right thing to do Mike? thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 19 17:34: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 RAA19203 for ; Tue, 19 Nov 2002 17:34:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAJMaoA20625 for nsis-archive@odin.ietf.org; Tue, 19 Nov 2002 17:36: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 gAJMaUv20616; Tue, 19 Nov 2002 17:36:30 -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 gAJMVFv20359 for ; Tue, 19 Nov 2002 17:31:15 -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 RAA19037 for ; Tue, 19 Nov 2002 17:28:29 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gAJMV2u4025679; Tue, 19 Nov 2002 14:31:02 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAQ61409; Tue, 19 Nov 2002 14:25:28 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA17139; Tue, 19 Nov 2002 14:31:06 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15834.48042.479284.224534@thomasm-u1.cisco.com> Date: Tue, 19 Nov 2002 14:31:06 -0800 (PST) To: Cc: , Subject: RE: [NSIS] Updated Charter In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I don't know about others, but the thought of having signaling alter forwarding decisions seems fairly scary. Treatment within the same queue seems fairly well understood, but having something outside of the well established routing protocols diddle with FIB's... well, let's say that the current crop of routing protocols were ironed out with much blood and sweat, and on a network long long ago, in a galaxy far far away. john.loughney@nokia.com writes: > Hi Michael, > > > So I'm somewhat confused about the earlier > > exchange today about whether signaling to alter > > the route packets take is in or out of scope, but > > if it's in, it seems really odd to leave such a > > large deliverable out of the charter. As in, I'd > > imagine that a lot of the routing area folks would > > probably be highly interested in such a thing, and > > it wouldn't be very obvious that it was happening > > here. > > So, I would prefer not to affect routing - any more > than what RSVP currently does. I'm not a routing expert, so I worry > that this would be a big can of worms. However, what does the WG think > about this? Do you have an opinion on what would be the right thing to > do Mike? > > thanks, > John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 19 21:22: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 VAA27296 for ; Tue, 19 Nov 2002 21:22:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK2Oa201604 for nsis-archive@odin.ietf.org; Tue, 19 Nov 2002 21:24:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAK2OXv01597; Tue, 19 Nov 2002 21:24: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 gAK2N9v01444 for ; Tue, 19 Nov 2002 21:23:09 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27150 for ; Tue, 19 Nov 2002 21:20:23 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Nov 2002 02:23:00 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5F20@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Michael Thomas , john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] Updated Charter Date: Wed, 20 Nov 2002 02:22:58 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi all, I hope that the terminology discussion has not sown more confusion (assuming that's what is being referred to). My understanding/opinion is the following: 1. there is no proposal anywhere on the table to have NSIS w.g. develop something which alters the routes that packets takes (either by distributing routes, fiddling with FIBs, or anything else). 2. it is certainly the case that the NTLP could never do this: it is simply responsible for moving signalling packets around, and in many (most?) cases will simply use normal IP routing to do this. (see also http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02178.html.) 3. we can't rule out someone designing an NSLP some day which carries routing information, although doing this in a general sense seems not meaningful to me in the context of path-coupled signalling - how do you signal to set up a path in a path coupled way? (see also http://www.ietf.org/mail-archive/working-groups/nsis/current/msg01903.html.) The reason for the terminology point being raised is that operation of the NTLP/NSLPs may be severely affected by the existence of 'policy forwarding' especially in NSIS-unaware (oops! invalid terminology) parts of the network. So, we wanted the term 'policy forwarding' as an unambiguous shorthand for the circumstances we are worried about. Hope this helps, Cheers, Robert H. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: 19 November 2002 17:31 > To: john.loughney@nokia.com > Cc: mat@cisco.com; nsis@ietf.org > Subject: RE: [NSIS] Updated Charter > > > > I don't know about others, but the thought of > having signaling alter forwarding decisions seems > fairly scary. Treatment within the same queue > seems fairly well understood, but having something > outside of the well established routing protocols > diddle with FIB's... well, let's say that the > current crop of routing protocols were ironed > out with much blood and sweat, and on a network > long long ago, in a galaxy far far away. > > john.loughney@nokia.com writes: > > Hi Michael, > > > > > So I'm somewhat confused about the earlier > > > exchange today about whether signaling to alter > > > the route packets take is in or out of scope, but > > > if it's in, it seems really odd to leave such a > > > large deliverable out of the charter. As in, I'd > > > imagine that a lot of the routing area folks would > > > probably be highly interested in such a thing, and > > > it wouldn't be very obvious that it was happening > > > here. > > > > So, I would prefer not to affect routing - any more > > than what RSVP currently does. I'm not a routing expert, > so I worry > > that this would be a big can of worms. However, what does > the WG think > > about this? Do you have an opinion on what would be the > right thing to > > do Mike? > > > > thanks, > > John > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 19 21:52: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 VAA29749 for ; Tue, 19 Nov 2002 21:52:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK2tCl03553 for nsis-archive@odin.ietf.org; Tue, 19 Nov 2002 21:55: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 gAK2t9v03545; Tue, 19 Nov 2002 21:55: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 gAK2swv03509 for ; Tue, 19 Nov 2002 21:54:58 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29732 for ; Tue, 19 Nov 2002 21:52:11 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Nov 2002 02:54:48 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5F21@rsys002a.roke.co.uk> From: "Hancock, Robert" To: john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] Updated Charter Date: Wed, 20 Nov 2002 02:54:47 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , John, A couple of comments related to non-routing issues: 1. I'll record my comment in the meeting that defining QoS classes, parameters, service types, pre-emption capability, you name it, should be a non-goal (I don't know if it needs to be explicit). 2. I note that an NSLP for a midcom application is not a charter goal initially (and even in the future might be an activity for another w.g. anyway). However, I'd still like to capture the relevance of a midcom-like application as a user (of the NTLP). In particular, we should be clear that discussion of it (and indeed other applications, like network path monitoring as mentioned at the meeting) is 'in scope' for the overall work, e.g. of the framework and security documents. (Again, I don't know if this needs to be explicit.) cheers, robert h. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 19 November 2002 14:43 > To: nsis@ietf.org > Subject: [NSIS] Updated Charter > > > Hi all, > > Here is the updated charter I presented at IETF55 today. > Please send comments. > > John > > Next Steps in Signaling (nsis) Charter > > Chair(s): > J. Loughney > > Transport Area Director(s): > S. Bradner > A. Mankin > > Transport Area Advisor: > A. Mankin > > Mailing Lists: > General Discussion: nsis@ietf.org > To Subscribe: nsis-request@ietf.org > In Body: (un)subscribe > Archive: > www.ietf.org/mail-archive/working-groups/nsis/current/maillist.html > > Description of Working Group: > > The Next Steps in Signaling Working Group is responsible for > standardizing an IP signaling protocol with QoS signaling as > the use case for NSIS. This working group will concentrate > on a two-layer signaling paradigm. The intention is to > re-use, where appropriate, the protocol mechanisms of RSVP, > while at the same time simplifying it and applying a more > general signaling model. > > The existing work on the requirements, the framework and > analysis of existing protocols will be completed and used as > input for the protocol work. > > NSIS will develop a transport layer signaling protocol for > the transport of upper layer signaling. In order to support a > tool box or building block approach, the two-layer model will > be used to seperate the transport of the signaling from the > application signaling. This allows for a more general > signaling protocol to be developed to support signaling for > different services or resources, such as NAT & firewall > traversal and QoS resources. The initial NSIs application > layer will be an optimzed RSVP signaling. Potential for a > second NSIS application layer, in order to ensure a generic > transport signaling protocol, will be considered in > consultation with the Transport Area directors. > > Security is a very important concern for NSIS. The working > group will study and analyze the threats and security > requirements for signaling. Compatibility with authentication > and authorization mechanisms such as those of Diameter, > COPS-PR, and RSVP-PR auth-session, will be addressed. > > It is a non-goal of the working group to develop new resource > allocation protocols. Resource reservation and traffic > engineering are out of scope of this working group. > Additionally, third party signaling is out of scope of this > working group. Mobility protocols and AAA work are out of > scope of the working group. The work produced in this Working > Group should work with existing IETF mobility and AAA > protocols, including (but not limited to) Mobile IP, SeaMoby > Context also welcomes participation and expression of > requirements from non-IETF standards organization members, > for instance 3GPP, 3GPP2 and ITU-T. > > Goals and Milestones: > > JAN 03 Submit "Requirements for Signaling Protocols" > to IESG for publication as Informational RFC > MAR 03 Submit "RSVP Security Properties" to IESG as > Informational RFC > APR 03 Submit "NSIS Threats" to IESG as Informational RFC > JUN 03 Submit "Analysis of Existing Signaling > Protocols" to IESG as Informational RFC > AUG 03 Submit "Next Steps in Signaling: Framework" to > IESG for publication as Informational RFC > MAR 04 Submit "NSIS Transport Protocol" to IESG for > publication for Proposed Standard > MAR 04 Submit "NSIS QoS Application Protocol" to IESG > for publication for Proposed Standard > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 19 22:03: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 WAA00539 for ; Tue, 19 Nov 2002 22:03:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK368d03974 for nsis-archive@odin.ietf.org; Tue, 19 Nov 2002 22:06: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 gAK367v03964; Tue, 19 Nov 2002 22:06:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAK35Bv03911 for ; Tue, 19 Nov 2002 22:05:11 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00379 for ; Tue, 19 Nov 2002 22:02:23 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAK35pB00745 for ; Wed, 20 Nov 2002 05:05:51 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 20 Nov 2002 05:05:01 +0200 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Nov 2002 05:05:01 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Nov 2002 05:05:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Updated Charter Date: Wed, 20 Nov 2002 05:04:59 +0200 Message-ID: Thread-Topic: [NSIS] Updated Charter Thread-Index: AcKQQDPd4d4wv8ZGT1WKEuKdUwuK4gAOXNgg To: , X-OriginalArrivalTime: 20 Nov 2002 03:05:00.0678 (UTC) FILETIME=[9D56CA60:01C29041] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAK35Bv03912 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Robert, > 1. I'll record my comment in the meeting that defining QoS > classes, parameters, service types, pre-emption capability, > you name it, should be a non-goal (I don't know if it needs > to be explicit). OK. > 2. I note that an NSLP for a midcom application is not a > charter goal initially (and even in the future might be an > activity for another w.g. anyway). However, I'd still like to > capture the relevance of a midcom-like application as a user > (of the NTLP). In particular, we should be clear that > discussion of it (and indeed other applications, like network > path monitoring as mentioned at the meeting) is 'in scope' > for the overall work, e.g. of the framework and security > documents. (Again, I don't know if this needs to be explicit.) Actually, it is not in the charter yet because I did not get feedback from the ADs on this point. I think what we should do is indicate in the charter that there is a desire to have an additional user of the NTLP & then we can discuss what it should be on the list. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 19 22:12: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 WAA02229 for ; Tue, 19 Nov 2002 22:12:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAK3Ef904789 for nsis-archive@odin.ietf.org; Tue, 19 Nov 2002 22:14: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 gAK3Edv04782; Tue, 19 Nov 2002 22:14: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 gAK38uv04625 for ; Tue, 19 Nov 2002 22:08:56 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00853 for ; Tue, 19 Nov 2002 22:06:08 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAK39aB02291 for ; Wed, 20 Nov 2002 05:09:36 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 20 Nov 2002 05:08:46 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Nov 2002 05:08:46 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Nov 2002 05:08:45 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Nov 2002 05:08:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Updated Charter Date: Wed, 20 Nov 2002 05:08:44 +0200 Message-ID: Thread-Topic: [NSIS] Updated Charter Thread-Index: AcKQG13vaIbOrm/6Rb2mV86ENqLFewAFB7jA To: Cc: X-OriginalArrivalTime: 20 Nov 2002 03:08:44.0826 (UTC) FILETIME=[22F10FA0:01C29042] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAK38uv04626 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Mike, > I don't know about others, but the thought of > having signaling alter forwarding decisions seems > fairly scary. I agree completely. > Treatment within the same queue > seems fairly well understood, but having something > outside of the well established routing protocols > diddle with FIB's... well, let's say that the > current crop of routing protocols were ironed > out with much blood and sweat, and on a network > long long ago, in a galaxy far far away. Routing protocols should do routing. Transport protocols should transport. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 20 11:01: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 LAA23063 for ; Wed, 20 Nov 2002 11:01:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAKG3Q024599 for nsis-archive@odin.ietf.org; Wed, 20 Nov 2002 11:03: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 gAKG3Nv24543; Wed, 20 Nov 2002 11:03:23 -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 gAKE8av15767 for ; Wed, 20 Nov 2002 09:08:36 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19325 for ; Wed, 20 Nov 2002 09:05:55 -0500 (EST) Received: from cs.columbia.edu (cta.ietf55.ops.ietf.org [204.42.73.82]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gAKE8VYQ006478 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Nov 2002 09:08:32 -0500 (EST) Message-ID: <3DDB96E3.4020303@cs.columbia.edu> Date: Wed, 20 Nov 2002 09:06:27 -0500 From: Henning Schulzrinne Organization: Columbia University 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: "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] Updated Charter References: <76C92FBBFB58D411AE760090271ED41805DF5F20@rsys002a.roke.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Except that I'd use policy-based forwarding, since you're not forwarding the policy.... , although doing this in a general sense seems not meaningful to me in the context of path-coupled signalling - how do you signal to set up a path in a path coupled way? (see also http://www.ietf.org/mail-archive/working-groups/nsis/current/msg01903.html.) > > The reason for the terminology point being raised is that operation of the NTLP/NSLPs may be severely affected by the existence of 'policy forwarding' especially in NSIS-unaware (oops! invalid terminology) parts of the network. So, we wanted the term 'policy forwarding' as an unambiguous shorthand for the circumstances we are worried about. > > Hope this helps, _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 20 16:26: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 QAA01504 for ; Wed, 20 Nov 2002 16:26:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAKLTAF15704 for nsis-archive@odin.ietf.org; Wed, 20 Nov 2002 16:29:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAKLT3v15690; Wed, 20 Nov 2002 16:29: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 gAKLRiv15656 for ; Wed, 20 Nov 2002 16:27:44 -0500 Received: from iramx2.ira.uni-karlsruhe.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01486 for ; Wed, 20 Nov 2002 16:24:59 -0500 (EST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 18EcNk-0006oI-00 for ; Wed, 20 Nov 2002 22:27:36 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=tpce10.ipv6.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 18EcNk-00040S-00; Wed, 20 Nov 2002 22:27:36 +0100 Received: from tm.uka.de (i72pc127.tm.uni-karlsruhe.de [141.3.70.78]) by tpce10.ipv6.tm.uka.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id gAKLR6e24767; Wed, 20 Nov 2002 22:27:06 +0100 Message-ID: <3DDC0CA3.4080208@tm.uka.de> Date: Wed, 20 Nov 2002 23:28:51 +0100 From: Roland Bless User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.1) Gecko/20020826 X-Accept-Language: de-at, de, en-us, en MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] scope of framework document Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, coming back to John's statement at the meeting that he likes short documents: I got the impression that the framework document currently contains a lot of solution-oriented stuff that would rather belong to a protocol design (discussion) document. Having two separate layers is a design decision to me that has its advantages, but now there are issues in the framework coming up like "which functions belong to which layer?". Doesn't this rather belong to a protocol design document? In my understanding, the main WG documents would cover: - analysis of existing signaling protocols -> why we might need a new signaling protocol, shortcomings and lessons learned - requirements -> functions and features that a signaling protocol should possess (mainly derived from various scenarios/use cases) - framework -> general interaction models and possible applications of the protocol in different environments. So the currently discussed options for the structure of a protocol may be derived from the framework, requirements and analysis documents, but should be kept/discussed IMHO in a separate protocol design document. Cheers, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 20 16:46: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 QAA02108 for ; Wed, 20 Nov 2002 16:46:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAKLn9617269 for nsis-archive@odin.ietf.org; Wed, 20 Nov 2002 16:49:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAKLn6v17262; Wed, 20 Nov 2002 16:49:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAKLmvv17248 for ; Wed, 20 Nov 2002 16:48:57 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02093 for ; Wed, 20 Nov 2002 16:46:11 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Nov 2002 21:48:49 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5F6F@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Roland Bless , nsis@ietf.org Subject: RE: [NSIS] scope of framework document Date: Wed, 20 Nov 2002 21:48:48 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all, having spent some time worrying about what should go in this document, i also have some views on the issue. the main concern i have with the discussion below is in the parts that go '...the protocol...'. there isn't such a thing, there is (unless I have got very confused) an assumption of a general purpose transport protocol with a set of signalling application protocols above it. if the 'top-level' framework document simply discusses how the NSIS protocols ***as a group*** might interact with the rest of the world and do interesting things, i don't see how that really advances our work. in particular, there is no obvious point at which to stop thinking of and describing new signalling applications which could have clever and complex interactions with the outside world. also, we are basically stumped at the moment on the security issues because it's impossible to make progress without having a more concrete structure to analyse, so we need to start breaking up the problem to make progress here. i would much rather trim the framework (if it needs trimming) from the top: i.e. work out the approximate layer split (which would actually be progress) and then move the signalling application specific aspects into a separate document. in particular, in such a separate document, we could relax from pretending we weren't talking about QoS when we really were. the other way to trim the document is to make progress on some of the open issues, in which case we could segregate some of the discussion and option analysis. (hint.) cheers, robert h. > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de] > Sent: 20 November 2002 17:29 > To: nsis@ietf.org > Subject: [NSIS] scope of framework document > > > Hi, > > coming back to John's statement at the meeting that he likes > short documents: > I got the impression that the framework document currently > contains a lot of solution-oriented stuff that would rather belong > to a protocol design (discussion) document. Having two separate > layers is a design decision to me that has its advantages, > but now there are issues in the framework coming up like > "which functions belong to which layer?". Doesn't this rather > belong to a protocol design document? In my understanding, > the main WG documents would cover: > - analysis of existing signaling protocols > -> why we might need a new signaling protocol, shortcomings > and lessons learned > - requirements -> functions and features that a signaling > protocol should > possess (mainly derived from various scenarios/use cases) > - framework -> general interaction models and possible applications > of the protocol in different environments. > > So the currently discussed options for the structure of a > protocol may be > derived from the framework, requirements and analysis documents, but > should be kept/discussed IMHO in a separate protocol design document. > > Cheers, > Roland > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 21 13: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 NAA15379 for ; Thu, 21 Nov 2002 13:46:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALImSk06143 for nsis-archive@odin.ietf.org; Thu, 21 Nov 2002 13:48: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 gALImOv06116; Thu, 21 Nov 2002 13:48: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 gALIfbv05864 for ; Thu, 21 Nov 2002 13:41:37 -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 NAA15140 for ; Thu, 21 Nov 2002 13:38:51 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gALIfDsA013007; Thu, 21 Nov 2002 10:41:17 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAR13366; Thu, 21 Nov 2002 10:35:48 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA17577; Thu, 21 Nov 2002 10:41:21 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15837.10448.905840.851995@thomasm-u1.cisco.com> Date: Thu, 21 Nov 2002 10:41:20 -0800 (PST) To: "Hancock, Robert" Cc: Michael Thomas , john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] Updated Charter In-Reply-To: <76C92FBBFB58D411AE760090271ED41805DF5F20@rsys002a.roke.co.uk> References: <76C92FBBFB58D411AE760090271ED41805DF5F20@rsys002a.roke.co.uk> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Robert, Can I make a general suggestion that terminology which describes things that the wg isn't going to address be elided? It's fairly easy to misconstrue aims when time has gone into defining something that could conceivably be worked on but that isn't charter. Or alternatively, you can tell me to pay more attention. Mike Hancock, Robert writes: > Hi all, > > I hope that the terminology discussion has not sown more confusion (assuming that's what is being referred to). > > My understanding/opinion is the following: > 1. there is no proposal anywhere on the table to have NSIS w.g. develop something which alters the routes that packets takes (either by distributing routes, fiddling with FIBs, or anything else). > 2. it is certainly the case that the NTLP could never do this: it is simply responsible for moving signalling packets around, and in many (most?) cases will simply use normal IP routing to do this. (see also http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02178.html.) > 3. we can't rule out someone designing an NSLP some day which carries routing information, although doing this in a general sense seems not meaningful to me in the context of path-coupled signalling - how do you signal to set up a path in a path coupled way? (see also http://www.ietf.org/mail-archive/working-groups/nsis/current/msg01903.html.) > > The reason for the terminology point being raised is that operation of the NTLP/NSLPs may be severely affected by the existence of 'policy forwarding' especially in NSIS-unaware (oops! invalid terminology) parts of the network. So, we wanted the term 'policy forwarding' as an unambiguous shorthand for the circumstances we are worried about. > > Hope this helps, > > Cheers, > > Robert H. > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: 19 November 2002 17:31 > > To: john.loughney@nokia.com > > Cc: mat@cisco.com; nsis@ietf.org > > Subject: RE: [NSIS] Updated Charter > > > > > > > > I don't know about others, but the thought of > > having signaling alter forwarding decisions seems > > fairly scary. Treatment within the same queue > > seems fairly well understood, but having something > > outside of the well established routing protocols > > diddle with FIB's... well, let's say that the > > current crop of routing protocols were ironed > > out with much blood and sweat, and on a network > > long long ago, in a galaxy far far away. > > > > john.loughney@nokia.com writes: > > > Hi Michael, > > > > > > > So I'm somewhat confused about the earlier > > > > exchange today about whether signaling to alter > > > > the route packets take is in or out of scope, but > > > > if it's in, it seems really odd to leave such a > > > > large deliverable out of the charter. As in, I'd > > > > imagine that a lot of the routing area folks would > > > > probably be highly interested in such a thing, and > > > > it wouldn't be very obvious that it was happening > > > > here. > > > > > > So, I would prefer not to affect routing - any more > > > than what RSVP currently does. I'm not a routing expert, > > so I worry > > > that this would be a big can of worms. However, what does > > the WG think > > > about this? Do you have an opinion on what would be the > > right thing to > > > do Mike? > > > > > > thanks, > > > John > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments is confidential to Roke > Manor Research Ltd and must not be passed to any third party without permission. This > communication is for information only and shall not create or change any contractual > relationship. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 21 15:38: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 PAA19033 for ; Thu, 21 Nov 2002 15:38:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALKeQB13951 for nsis-archive@odin.ietf.org; Thu, 21 Nov 2002 15:40: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 gALKeKv13931; Thu, 21 Nov 2002 15:40: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 gALKd3v13862 for ; Thu, 21 Nov 2002 15:39:03 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18976 for ; Thu, 21 Nov 2002 15:36:18 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gALKcsL07878; Thu, 21 Nov 2002 12:38:54 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id UAA10311; Thu, 21 Nov 2002 20:38:54 GMT Date: Thu, 21 Nov 2002 20:38:54 GMT Message-Id: <200211212038.UAA10311@gra.isi.edu> To: john.loughney@nokia.com, nsis@ietf.org, robert.hancock@roke.co.uk Subject: RE: [NSIS] Updated Charter X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> John, *> *> A couple of comments related to non-routing issues: *> *> 1. I'll record my comment in the meeting that defining QoS classes, parameters, service types, pre-emption capability, you name it, should be a non-goal (I don't know if it needs to be explicit). *> *> 2. I note that an NSLP for a midcom application is not a charter goal initially (and even in the future might be an activity for another w.g. anyway). However, I'd still like to capture the relevance of a midcom-like application as a user (of the NTLP). In particular, we should be clear that discussion of it (and indeed other applications, like network path monitoring as mentioned at the meeting) is 'in scope' for the overall work, e.g. of the framework and security documents. (Again, I don't know if this needs to be explicit.) *> *> cheers, *> *> robert h. *> I agree with both points. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 21 15:40: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 PAA19204 for ; Thu, 21 Nov 2002 15:40:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALKhCe14157 for nsis-archive@odin.ietf.org; Thu, 21 Nov 2002 15:43: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 gALKh2v14128; Thu, 21 Nov 2002 15:43: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 gALKgYv14065 for ; Thu, 21 Nov 2002 15:42:34 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19116 for ; Thu, 21 Nov 2002 15:39:49 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gALKgRL09992; Thu, 21 Nov 2002 12:42:27 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id UAA10327; Thu, 21 Nov 2002 20:42:27 GMT Date: Thu, 21 Nov 2002 20:42:27 GMT Message-Id: <200211212042.UAA10327@gra.isi.edu> To: john.loughney@nokia.com Subject: RE: [NSIS] Updated Charter Cc: nsis@ietf.org, braden@ISI.EDU X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> Routing protocols should do routing. Transport *> protocols should transport. *> And "signaling protocols should do signaling"? ;-) Although I do (continue to) agree that separating routing from signaling is the better modularity, the issues of QoS routing and route-pinning are real and hard, and hence the interface between them is important. Bob Braden *> John *> _______________________________________________ *> nsis mailing list *> nsis@ietf.org *> https://www1.ietf.org/mailman/listinfo/nsis *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 21 15:46: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 PAA19469 for ; Thu, 21 Nov 2002 15:46:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALKn8b14443 for nsis-archive@odin.ietf.org; Thu, 21 Nov 2002 15:49: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 gALKn5v14436; Thu, 21 Nov 2002 15:49: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 gALKm7v14387 for ; Thu, 21 Nov 2002 15:48:07 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19393 for ; Thu, 21 Nov 2002 15:45:21 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gALKlwL12093; Thu, 21 Nov 2002 12:47:58 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id UAA10330; Thu, 21 Nov 2002 20:47:58 GMT Date: Thu, 21 Nov 2002 20:47:58 GMT Message-Id: <200211212047.UAA10330@gra.isi.edu> To: nsis@ietf.org, bless@tm.uka.de Subject: Re: [NSIS] scope of framework document X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> belong to a protocol design document? In my understanding, *> the main WG documents would cover: *> - analysis of existing signaling protocols *> -> why we might need a new signaling protocol, shortcomings *> and lessons learned *> - requirements -> functions and features that a signaling protocol should *> possess (mainly derived from various scenarios/use cases) *> - framework -> general interaction models and possible applications *> of the protocol in different environments. *> Hmmm. Cries of "rough consensus and running code" were heard in the land. We should be sure that "top down" does not become "top heavy". Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 21 16:04: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 QAA20379 for ; Thu, 21 Nov 2002 16:04:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALL6SC15447 for nsis-archive@odin.ietf.org; Thu, 21 Nov 2002 16:06: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 gALL6Lv15437; Thu, 21 Nov 2002 16:06: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 gALL5xv15397 for ; Thu, 21 Nov 2002 16:05:59 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20298 for ; Thu, 21 Nov 2002 16:03:13 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Nov 2002 20:20:27 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF5F95@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Subject: RE: [NSIS] Updated Charter Date: Thu, 21 Nov 2002 20:20:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Mike, Summary: 1. the wg isn't going to work on techniques for doing foo, but 2. the wg has a choice between: a. considering that foo happens anyway and we need to be able to work around it, or b. deciding that foo is not a problem in the environments the signalling will be used in. Do we need terminology for foo? But more importantly, what is your opinion between 2a and 2b? Robert PS for those joining the conversation late, "foo" = policy-based forwarding leading to signalling/data path divergence. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: 21 November 2002 13:41 > To: Hancock, Robert > Cc: Michael Thomas; john.loughney@nokia.com; nsis@ietf.org > Subject: RE: [NSIS] Updated Charter > > > > Robert, > > Can I make a general suggestion that terminology > which describes things that the wg isn't going to > address be elided? It's fairly easy to misconstrue > aims when time has gone into defining something > that could conceivably be worked on but that isn't > charter. > > Or alternatively, you can tell me to pay more > attention. > > Mike > > Hancock, Robert writes: > > Hi all, > > > > I hope that the terminology discussion has not sown more > confusion (assuming that's what is being referred to). > > > > My understanding/opinion is the following: > > 1. there is no proposal anywhere on the table to have NSIS > w.g. develop something which alters the routes that packets > takes (either by distributing routes, fiddling with FIBs, or > anything else). > > 2. it is certainly the case that the NTLP could never do > this: it is simply responsible for moving signalling packets > around, and in many (most?) cases will simply use normal IP > routing to do this. (see also > http://www.ietf.org/mail-archive/working-groups/nsis/current/m > sg02178.html.) > > 3. we can't rule out someone designing an NSLP some day > which carries routing information, although doing this in a > general sense seems not meaningful to me in the context of > path-coupled signalling - how do you signal to set up a path > in a path coupled way? (see also > http://www.ietf.org/mail-archive/working-groups/nsis/current/m > sg01903.html.) > > > > The reason for the terminology point being raised is that > operation of the NTLP/NSLPs may be severely affected by the > existence of 'policy forwarding' especially in NSIS-unaware > (oops! invalid terminology) parts of the network. So, we > wanted the term 'policy forwarding' as an unambiguous > shorthand for the circumstances we are worried about. > > > > Hope this helps, > > > > Cheers, > > > > Robert H. > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: 19 November 2002 17:31 > > > To: john.loughney@nokia.com > > > Cc: mat@cisco.com; nsis@ietf.org > > > Subject: RE: [NSIS] Updated Charter > > > > > > > > > > > > I don't know about others, but the thought of > > > having signaling alter forwarding decisions seems > > > fairly scary. Treatment within the same queue > > > seems fairly well understood, but having something > > > outside of the well established routing protocols > > > diddle with FIB's... well, let's say that the > > > current crop of routing protocols were ironed > > > out with much blood and sweat, and on a network > > > long long ago, in a galaxy far far away. > > > > > > john.loughney@nokia.com writes: > > > > Hi Michael, > > > > > > > > > So I'm somewhat confused about the earlier > > > > > exchange today about whether signaling to alter > > > > > the route packets take is in or out of scope, but > > > > > if it's in, it seems really odd to leave such a > > > > > large deliverable out of the charter. As in, I'd > > > > > imagine that a lot of the routing area folks would > > > > > probably be highly interested in such a thing, and > > > > > it wouldn't be very obvious that it was happening > > > > > here. > > > > > > > > So, I would prefer not to affect > routing - any more > > > > than what RSVP currently does. I'm not a routing expert, > > > so I worry > > > > that this would be a big can of worms. However, what does > > > the WG think > > > > about this? Do you have an opinion on what would be the > > > right thing to > > > > do Mike? > > > > > > > > thanks, > > > > John > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 21 16:16: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 QAA20860 for ; Thu, 21 Nov 2002 16:16:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALLH9o16662 for nsis-archive@odin.ietf.org; Thu, 21 Nov 2002 16:17:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALLH6v16655; Thu, 21 Nov 2002 16:17: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 gALLGpv16625 for ; Thu, 21 Nov 2002 16:16:51 -0500 Received: from iramx2.ira.uni-karlsruhe.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20764 for ; Thu, 21 Nov 2002 16:14:05 -0500 (EST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 18Eygl-00019i-00; Thu, 21 Nov 2002 22:16:43 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=tpce10.ipv6.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 18Eygm-0007ft-00; Thu, 21 Nov 2002 22:16:44 +0100 Received: from tm.uka.de (i72pc127.tm.uni-karlsruhe.de [141.3.70.78]) by tpce10.ipv6.tm.uka.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id gALLGCe28724; Thu, 21 Nov 2002 22:16:12 +0100 Message-ID: <3DDD5B8A.6090309@tm.uka.de> Date: Thu, 21 Nov 2002 23:17:46 +0100 From: Roland Bless User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.1) Gecko/20020826 X-Accept-Language: de-at, de, en-us, en MIME-Version: 1.0 To: Bob Braden CC: nsis@ietf.org Subject: Re: [NSIS] scope of framework document References: <200211212047.UAA10330@gra.isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bob, fully agreed. I was just proposing to trim the framework document a bit and to possibly put some stuff into a separate document, not to stop working towards a protocol. The given list just coarsely summarized what the documents contain (see abstracts). > *> belong to a protocol design document? In my understanding, > *> the main WG documents would cover: > *> - analysis of existing signaling protocols > *> -> why we might need a new signaling protocol, shortcomings > *> and lessons learned > *> - requirements -> functions and features that a signaling protocol should > *> possess (mainly derived from various scenarios/use cases) > *> - framework -> general interaction models and possible applications > *> of the protocol in different environments. > *> > >Hmmm. Cries of "rough consensus and running code" were heard in the land. >We should be sure that "top down" does not become "top heavy". > Regards, Roland > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 21 17:04: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 RAA22719 for ; Thu, 21 Nov 2002 17:04:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALM6gQ19910 for nsis-archive@odin.ietf.org; Thu, 21 Nov 2002 17:06: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 gALM6av19903; Thu, 21 Nov 2002 17:06:36 -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 gALM5Uv19833 for ; Thu, 21 Nov 2002 17:05:30 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22683 for ; Thu, 21 Nov 2002 17:02:43 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gALM6E626613 for ; Fri, 22 Nov 2002 00:06:14 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 22 Nov 2002 00:05:08 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 22 Nov 2002 00:05:08 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 22 Nov 2002 00:05:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Updated Charter Date: Fri, 22 Nov 2002 00:05:06 +0200 Message-ID: Thread-Topic: [NSIS] Updated Charter Thread-Index: AcKRnoPjRSi64sVgTsuv0PZJ2VekZQAAqYiw To: Cc: X-OriginalArrivalTime: 21 Nov 2002 22:05:07.0355 (UTC) FILETIME=[0D4F16B0:01C291AA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gALM5Uv19834 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Bob, > *> Routing protocols should do routing. Transport > *> protocols should transport. > *> > > And "signaling protocols should do signaling"? ;-) Exactly! > Although I do (continue to) agree that separating routing from > signaling is the better modularity, the issues of QoS routing and > route-pinning are real and hard, and hence the interface between > them is important. Yes, the transport layer should be aware of some of these issues, but we should be careful that we don't create an overlay network which we are routing the signaling messages on. If we do, then we can very easily have divergence of the signaling path from the data path. best regards, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 21 17:11: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 RAA22936 for ; Thu, 21 Nov 2002 17:11:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALMDOL20879 for nsis-archive@odin.ietf.org; Thu, 21 Nov 2002 17: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 gALMDCv20867; Thu, 21 Nov 2002 17:13: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 gALMAsv20680 for ; Thu, 21 Nov 2002 17:10:54 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22877 for ; Thu, 21 Nov 2002 17:08:08 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gALMAlL26691; Thu, 21 Nov 2002 14:10:47 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id WAA10383; Thu, 21 Nov 2002 22:10:47 GMT Date: Thu, 21 Nov 2002 22:10:47 GMT Message-Id: <200211212210.WAA10383@gra.isi.edu> To: braden@ISI.EDU, john.loughney@nokia.com Subject: RE: [NSIS] Updated Charter Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , John, *> Yes, the transport layer should be aware of some of these issues, *> but we should be careful that we don't create an overlay network *> which we are routing the signaling messages on. If we do, then *> we can very easily have divergence of the signaling path from *> the data path. (... among other evils) Mind you, maybe the Routing area should investigate whether there is room in the global routing architecture for some form of local fixups using some form of signaling. I am not a routing expert so this is only a wild idea. But that would surely have to be founded on a firm base of research in the routing area, and it must be totally out of scope for NSIS. Bob *> *> best regards, *> John *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 21 17:20: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 RAA23467 for ; Thu, 21 Nov 2002 17:20:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gALMM8o21411 for nsis-archive@odin.ietf.org; Thu, 21 Nov 2002 17:22: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 gALMM5v21404; Thu, 21 Nov 2002 17:22: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 gALMLav21370 for ; Thu, 21 Nov 2002 17:21:36 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23424 for ; Thu, 21 Nov 2002 17:18:50 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id gALMLSL03895; Thu, 21 Nov 2002 14:21:28 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id WAA10402; Thu, 21 Nov 2002 22:21:27 GMT Date: Thu, 21 Nov 2002 22:21:27 GMT Message-Id: <200211212221.WAA10402@gra.isi.edu> To: nsis@ietf.org, robert.hancock@roke.co.uk X-Sun-Charset: US-ASCII Subject: [NSIS] Policy-based forwarding Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , RE: policy-based forwarding. To make path-coupled signaling work, you have to ensure that the downstream signaling messages follow EXACTLY the path of the data, whatever that takes. If you are doing simple, standard IP forwarding based on destination address, it just works is the signaling messages carry the destination address of the data (as in RSVP Path messages). If you do something fancier for routing, like source routing or load balancing or policy-based routing, you have to do whatever it takes to make the signaling messages follow the same path. To the extent that forwarding depends only upon packet header fields that can be made identical between the data packets and the signaling packets, it will just work. If the node is ISPS-capable, you just have to ensure that the NF entity knows how to do the right thing in forwarding the signaling packet. For compatible operation through non-ISPS-capable nodes, there will be combinations that just won't work. Your choices then are to (1) partially give up on path-coupled signaling, or (2) stop doing whatever funny routing is being done for those packets relevant to signaling, or (3) make all of your nodes ISPS-capable. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Nov 24 09:15: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 JAA27058 for ; Sun, 24 Nov 2002 09:15:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAOEI8K30007 for nsis-archive@odin.ietf.org; Sun, 24 Nov 2002 09:18: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 gAOEI0v29994; Sun, 24 Nov 2002 09:18: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 gAMED2v18851 for ; Fri, 22 Nov 2002 09:13:02 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25308 for ; Fri, 22 Nov 2002 09:10:18 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gAMECwl8016188 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 22 Nov 2002 09:12:59 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id gAMECvdG027702 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 22 Nov 2002 09:12:58 -0500 (EST) Message-ID: <3DDE3B53.5030305@cs.columbia.edu> Date: Fri, 22 Nov 2002 09:12:35 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: braden@isi.edu, nsis@ietf.org Subject: Re: [NSIS] Updated Charter References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In case this refers to my presentation on transport protocols: The use of transport protocols provably has no bearing on divergence. It neither increases it nor decreases it, assuming that discovery of next nodes is done at the same rate or using the same information (such as "triggered updates" based on local routing tables). I suspect we have a somewhat different model on how this might work, leading to different conclusions. > > Yes, the transport layer should be aware of some of these issues, > but we should be careful that we don't create an overlay network > which we are routing the signaling messages on. If we do, then > we can very easily have divergence of the signaling path from > the data path. > > best regards, > John > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 26 14:43: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 OAA17748 for ; Tue, 26 Nov 2002 14:43:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQJkCc20923 for nsis-archive@odin.ietf.org; Tue, 26 Nov 2002 14:46: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 gAQJkAv20911; Tue, 26 Nov 2002 14:46: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 gAQHstv12338 for ; Tue, 26 Nov 2002 12:54:55 -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 MAA13405 for ; Tue, 26 Nov 2002 12:52:06 -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 gAQHt2q20672 for ; Tue, 26 Nov 2002 11:55:02 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Nov 2002 11:54:48 -0600 Message-ID: <23BDB0046F3ED51185CD0002A5608D240706E661@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: nsis@ietf.org Date: Tue, 26 Nov 2002 11:54:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29574.E943B9F0" Subject: [NSIS] next peer issue in rsvp-sec Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling 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_01C29574.E943B9F0 Content-Type: text/plain Hi all, I think the Next Peer issue highlighted in the RSVP Security Properties slide (http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Properties.ppt) can be solved by adding an ERO (EXPLICIT_ROUTE object) in the RSVP-PATH message. Of course the intervening network needs to understand ERO. -Kuntal ------_=_NextPart_001_01C29574.E943B9F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable next peer issue in rsvp-sec

Hi all,
I think the Next Peer issue highlighted in the RSVP = Security Properties slide
(http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security= -Properties.ppt)
can be solved by adding an ERO (EXPLICIT_ROUTE = object) in the RSVP-PATH message.
Of course the intervening network needs to = understand ERO.

-Kuntal

------_=_NextPart_001_01C29574.E943B9F0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Nov 26 18:53: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 SAA27386 for ; Tue, 26 Nov 2002 18:53:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAQNu5W05042 for nsis-archive@odin.ietf.org; Tue, 26 Nov 2002 18:56:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAQNu2v04985; Tue, 26 Nov 2002 18:56: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 gAQNobv04767 for ; Tue, 26 Nov 2002 18:50:37 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27179 for ; Tue, 26 Nov 2002 18:47:46 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Nov 2002 23:50:29 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF6017@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Kuntal Chowdhury , nsis@ietf.org Subject: RE: [NSIS] next peer issue in rsvp-sec Date: Tue, 26 Nov 2002 23:50:26 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C295A6.96FBF680" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling 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_01C295A6.96FBF680 Content-Type: text/plain; charset="iso-8859-1" Hi, I don't believe that the ERO is relevant here. The issue isn't that the messages get sent to the wrong next peer (which the ERO would fix, albeit in a somewhat overweight way), it's that they are sent to the right next peer, but with the wrong security association, because the source didn't know the next peer had changed. So this is essentially an issue of how to discover and react to route changes. (At least I think so.) Cheers, Robert H. -----Original Message----- From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] Sent: 26 November 2002 17:55 To: nsis@ietf.org Subject: [NSIS] next peer issue in rsvp-sec Hi all, I think the Next Peer issue highlighted in the RSVP Security Properties slide ( http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Properties.ppt ) can be solved by adding an ERO (EXPLICIT_ROUTE object) in the RSVP-PATH message. Of course the intervening network needs to understand ERO. -Kuntal ------_=_NextPart_001_01C295A6.96FBF680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable next peer issue in rsvp-sec
Hi,
 
I=20 don't believe that the ERO is relevant here. The issue isn't that the = messages=20 get sent to the wrong next peer (which the ERO would fix, albeit in=20 a somewhat overweight way), it's that they are sent to the = right next=20 peer, but with the wrong security association, because the source = didn't know=20 the next peer had changed. So this is essentially an issue of how to = discover=20 and react to route changes. (At least I think so.)
 
Cheers,
 
Robert=20 H.
-----Original Message-----
From: Kuntal Chowdhury=20 [mailto:chowdury@nortelnetworks.com]
Sent: 26 November 2002 = 17:55
To: nsis@ietf.org
Subject: [NSIS] next peer = issue in=20 rsvp-sec

Hi all,
I think the Next = Peer issue=20 highlighted in the RSVP Security Properties slide
(http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Properties= .ppt)=20
can be solved by adding an ERO = (EXPLICIT_ROUTE object)=20 in the RSVP-PATH message.
Of course the = intervening=20 network needs to understand ERO.

-Kuntal

------_=_NextPart_001_01C295A6.96FBF680-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 03:23: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 DAA03262 for ; Wed, 27 Nov 2002 03:23:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAR8QJI07338 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 03:26:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAR8QGv07331; Wed, 27 Nov 2002 03:26: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 gAR8Kiv07200 for ; Wed, 27 Nov 2002 03:20:44 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03185 for ; Wed, 27 Nov 2002 03:17:49 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gAR7pom32117; Wed, 27 Nov 2002 08:51:50 +0100 Subject: RE: [NSIS] next peer issue in rsvp-sec To: "Hancock, Robert" Cc: Kuntal Chowdhury , nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 27 Nov 2002 08:51:48 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/27/2002 08:51:50 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAR8Kiv07201 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Robert, Kuntal, all, I interpreted the ERO comment as follows: The fact that the security association is now wrong results from the route change. The ERO is a way to pin the route to what it originally was and thus prevents the route change. This means that the security association will be the correct one. What do you think? Cheers, Sven. "Hancock, Robert" @ietf.org on 27/11/2002 00:50:26 Sent by: nsis-admin@ietf.org To: Kuntal Chowdhury , nsis@ietf.org cc: Subject: RE: [NSIS] next peer issue in rsvp-sec Hi, I don't believe that the ERO is relevant here. The issue isn't that the messages get sent to the wrong next peer (which the ERO would fix, albeit in a somewhat overweight way), it's that they are sent to the right next peer, but with the wrong security association, because the source didn't know the next peer had changed. So this is essentially an issue of how to discover and react to route changes. (At least I think so.) Cheers, Robert H. -----Original Message----- From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] Sent: 26 November 2002 17:55 To: nsis@ietf.org Subject: [NSIS] next peer issue in rsvp-sec Hi all, I think the Next Peer issue highlighted in the RSVP Security Properties slide (http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Properties.ppt) can be solved by adding an ERO (EXPLICIT_ROUTE object) in the RSVP-PATH message. Of course the intervening network needs to understand ERO. -Kuntal _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 03:48: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 DAA03607 for ; Wed, 27 Nov 2002 03:48:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAR8p0p08820 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 03:51: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 gAR8owv08802; Wed, 27 Nov 2002 03:50: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 gAR8jDv08614 for ; Wed, 27 Nov 2002 03:45:13 -0500 Received: from pimout4-ext.prodigy.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03540 for ; Wed, 27 Nov 2002 03:42:18 -0500 (EST) Received: from cs.columbia.edu (adsl-66-127-242-132.dsl.sntc01.pacbell.net [66.127.242.132]) by pimout4-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id gAR8iqAQ424282; Wed, 27 Nov 2002 03:44:57 -0500 Message-ID: <3DE48607.2090908@cs.columbia.edu> Date: Wed, 27 Nov 2002 00:44:55 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sven.van_den_bosch@alcatel.be CC: "Hancock, Robert" , Kuntal Chowdhury , nsis@ietf.org Subject: Re: [NSIS] next peer issue in rsvp-sec References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I thought ERO was invented for traffic engineering. Why is it relevant to security? This entire RSVP security thread sounds fishy to me. RSVP is no different than IGP, where control messages are passed hop-by-hop. If people are happy with how routing protocols are handling with their security issues (MD5 and what not), then RSVP should just adapt the same mechanism. I know some people are not happy with routing security in the first place, then maybe this entire protocol security issue should be considered else where. Finally, I am just curious about where this NSIS protocol would get deployed to have this security problem. In the backbone, RSVP-TE seems to be fine as it is. I wonder if this is designed for mobile users. Thanks! - Ping sven.van_den_bosch@alcatel.be wrote: > Hi Robert, Kuntal, all, > > I interpreted the ERO comment as follows: The fact that the security > association is now wrong results from the route change. The ERO is a way to > pin the route to what it originally was and thus prevents the route change. > This means that the security association will be the correct one. What do > you think? > > Cheers, > Sven. > > > > > > "Hancock, Robert" @ietf.org on 27/11/2002 > 00:50:26 > > Sent by: nsis-admin@ietf.org > > > To: Kuntal Chowdhury , nsis@ietf.org > cc: > Subject: RE: [NSIS] next peer issue in rsvp-sec > > > > Hi, > > I don't believe that the ERO is relevant here. The issue isn't that the > messages get sent to the wrong next peer (which the ERO would fix, albeit > in a somewhat overweight way), it's that they are sent to the right next > peer, but with the wrong security association, because the source didn't > know the next peer had changed. So this is essentially an issue of how to > discover and react to route changes. (At least I think so.) > > Cheers, > > Robert H. > -----Original Message----- > From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] > Sent: 26 November 2002 17:55 > To: nsis@ietf.org > Subject: [NSIS] next peer issue in rsvp-sec > > > > Hi all, > I think the Next Peer issue highlighted in the RSVP Security Properties > slide > (http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Properties.ppt) > can be solved by adding an ERO (EXPLICIT_ROUTE object) in the RSVP-PATH > message. > Of course the intervening network needs to understand ERO. > > -Kuntal > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 06:09: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 GAA05766 for ; Wed, 27 Nov 2002 06:09:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARBCBt16871 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 06:12: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 gARBC9v16864; Wed, 27 Nov 2002 06:12: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 gARB65v16130 for ; Wed, 27 Nov 2002 06:06:05 -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 GAA05669 for ; Wed, 27 Nov 2002 06:03:19 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gARB5Z0R028409; Wed, 27 Nov 2002 03:05:35 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAS71258; Wed, 27 Nov 2002 02:58:45 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id DAA18853; Wed, 27 Nov 2002 03:05:37 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15844.42753.759809.561968@thomasm-u1.cisco.com> Date: Wed, 27 Nov 2002 03:05:37 -0800 (PST) To: Ping Pan Cc: sven.van_den_bosch@alcatel.be, "Hancock, Robert" , Kuntal Chowdhury , nsis@ietf.org Subject: Re: [NSIS] next peer issue in rsvp-sec In-Reply-To: <3DE48607.2090908@cs.columbia.edu> References: <3DE48607.2090908@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In fact, RSVP has two different authentication needs: hop-by-hop which is fairly analogous to the IGP problem and the more abstract e2e/e2m/m2m kind of problem which RFC 2752 talks about. This problem is both a) harder and b) not unique to RSVP (SIP and any other proxiable protocol usually run into the same problem). What I keep wondering about is whether an app layer auth/encryption abstraction would be useful for all (or many at least) of these problems that keep popping up. SIP, for example, did a pretty bad job of solving this problem. Mike Ping Pan writes: > I thought ERO was invented for traffic engineering. Why is it relevant > to security? > > This entire RSVP security thread sounds fishy to me. RSVP is no > different than IGP, where control messages are passed hop-by-hop. If > people are happy with how routing protocols are handling with their > security issues (MD5 and what not), then RSVP should just adapt the same > mechanism. I know some people are not happy with routing security in the > first place, then maybe this entire protocol security issue should be > considered else where. > > Finally, I am just curious about where this NSIS protocol would get > deployed to have this security problem. In the backbone, RSVP-TE seems > to be fine as it is. I wonder if this is designed for mobile users. > > Thanks! > > - Ping > > > sven.van_den_bosch@alcatel.be wrote: > > Hi Robert, Kuntal, all, > > > > I interpreted the ERO comment as follows: The fact that the security > > association is now wrong results from the route change. The ERO is a way to > > pin the route to what it originally was and thus prevents the route change. > > This means that the security association will be the correct one. What do > > you think? > > > > Cheers, > > Sven. > > > > > > > > > > > > "Hancock, Robert" @ietf.org on 27/11/2002 > > 00:50:26 > > > > Sent by: nsis-admin@ietf.org > > > > > > To: Kuntal Chowdhury , nsis@ietf.org > > cc: > > Subject: RE: [NSIS] next peer issue in rsvp-sec > > > > > > > > Hi, > > > > I don't believe that the ERO is relevant here. The issue isn't that the > > messages get sent to the wrong next peer (which the ERO would fix, albeit > > in a somewhat overweight way), it's that they are sent to the right next > > peer, but with the wrong security association, because the source didn't > > know the next peer had changed. So this is essentially an issue of how to > > discover and react to route changes. (At least I think so.) > > > > Cheers, > > > > Robert H. > > -----Original Message----- > > From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] > > Sent: 26 November 2002 17:55 > > To: nsis@ietf.org > > Subject: [NSIS] next peer issue in rsvp-sec > > > > > > > > Hi all, > > I think the Next Peer issue highlighted in the RSVP Security Properties > > slide > > (http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Properties.ppt) > > can be solved by adding an ERO (EXPLICIT_ROUTE object) in the RSVP-PATH > > message. > > Of course the intervening network needs to understand ERO. > > > > -Kuntal > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 07:58: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 HAA07898 for ; Wed, 27 Nov 2002 07:58:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARD1Ew23721 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 08:01: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 gARD1Bv23706; Wed, 27 Nov 2002 08:01: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 gARCvSv23545 for ; Wed, 27 Nov 2002 07:57:28 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07797 for ; Wed, 27 Nov 2002 07:54:41 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gARCwP628158 for ; Wed, 27 Nov 2002 14:58:25 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Nov 2002 14:57:24 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Nov 2002 14:57:24 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Nov 2002 14:57:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] next peer issue in rsvp-sec Date: Wed, 27 Nov 2002 14:57:23 +0200 Message-ID: Thread-Topic: [NSIS] next peer issue in rsvp-sec Thread-Index: AcKWEnQktffhzKiuTQqS4B56XTygkgAAdhAQ To: Cc: X-OriginalArrivalTime: 27 Nov 2002 12:57:23.0688 (UTC) FILETIME=[8783F680:01C29614] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gARCvSv23546 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Michael, > In fact, RSVP has two different authentication > needs: hop-by-hop which is fairly analogous to the > IGP problem and the more abstract e2e/e2m/m2m kind > of problem which RFC 2752 talks about. This > problem is both a) harder and b) not unique to > RSVP (SIP and any other proxiable protocol usually > run into the same problem). Exactly. > What I keep wondering about is whether an app > layer auth/encryption abstraction would be useful > for all (or many at least) of these problems that > keep popping up. SIP, for example, did a pretty > bad job of solving this problem. So, I think that part of the 2 layer functional split that we need to work on should try to address this. I prefer to have the upper layer handle the authentication and payload encryption part. The lower layer could just work on transport layer security, which is very useful in protecting various DoS problems. Of course, the devil's in the details. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 08:09: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 IAA08337 for ; Wed, 27 Nov 2002 08:09:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARDBo524704 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 08:11: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 gARDBlv24697; Wed, 27 Nov 2002 08:11: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 gARD8hv24585 for ; Wed, 27 Nov 2002 08:08:43 -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 IAA08179 for ; Wed, 27 Nov 2002 08:05:58 -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 gARD8fcb028077; Wed, 27 Nov 2002 05:08:41 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABA20159; Wed, 27 Nov 2002 05:08:38 -0800 (PST) Message-Id: <200211271308.ABA20159@mira-sjc5-c.cisco.com> To: john.loughney@nokia.com cc: mat@cisco.com, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] next peer issue in rsvp-sec In-Reply-To: Message from john.loughney@nokia.com of "Wed, 27 Nov 2002 14:57:23 +0200." Date: Wed, 27 Nov 2002 08:08:38 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > So, I think that part of the 2 layer functional split > that we need to work on should try to address this. > I prefer to have the upper layer handle the authentication > and payload encryption part. I'd swap some words around and to say "upper layer handle the payload authentication and encryption part." Basically all we're saying is that the application needs to protect itself against threats against the application and that the transport layer needs to protect itself against threats against the transport. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 08:15: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 IAA08419 for ; Wed, 27 Nov 2002 08:15:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARDHnb24917 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 08:17: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 gARDHjv24910; Wed, 27 Nov 2002 08:17: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 gARDEwv24827 for ; Wed, 27 Nov 2002 08:14:58 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08388 for ; Wed, 27 Nov 2002 08:12:12 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gARDEJ910677 for ; Wed, 27 Nov 2002 15:14:19 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Nov 2002 15:14:53 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Nov 2002 15:14:52 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Nov 2002 15:14:51 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Nov 2002 15:14:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] next peer issue in rsvp-sec Date: Wed, 27 Nov 2002 15:14:50 +0200 Message-ID: Thread-Topic: [NSIS] next peer issue in rsvp-sec Thread-Index: AcKWFh8m6rUq9jKNTvSxScW7cPIFdAAANEkQ To: Cc: , X-OriginalArrivalTime: 27 Nov 2002 13:14:51.0377 (UTC) FILETIME=[F7FC9E10:01C29616] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gARDEwv24828 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Melinda, Your wordsmithing works for me. John > -----Original Message----- > From: ext Melinda Shore [mailto:mshore@cisco.com] > Sent: 27 November, 2002 15:09 > To: Loughney John (NRC/Helsinki) > Cc: mat@cisco.com; nsis@ietf.org > Subject: Re: [NSIS] next peer issue in rsvp-sec > > > > So, I think that part of the 2 layer functional split > > that we need to work on should try to address this. > > I prefer to have the upper layer handle the authentication > > and payload encryption part. > > I'd swap some words around and to say "upper layer handle > the payload authentication and encryption part." Basically > all we're saying is that the application needs to protect > itself against threats against the application and that the > transport layer needs to protect itself against threats > against the transport. > > Melinda > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 08:23: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 IAA08633 for ; Wed, 27 Nov 2002 08:23:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARDPlk25276 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 08:25: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 gARDPjv25265; Wed, 27 Nov 2002 08:25: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 gARDMgv25151 for ; Wed, 27 Nov 2002 08:22:42 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08579 for ; Wed, 27 Nov 2002 08:19:56 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gARDM3916705 for ; Wed, 27 Nov 2002 15:22:03 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Nov 2002 15:22:39 +0200 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Nov 2002 15:22:38 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Nov 2002 15:22:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 27 Nov 2002 15:22:38 +0200 Message-ID: Thread-Topic: [NSIS] Policy-based forwarding Thread-Index: AcKRrHSrBZW6xoTVTEWWDNZmxf43YgEaodTA To: X-OriginalArrivalTime: 27 Nov 2002 13:22:38.0640 (UTC) FILETIME=[0E7F4B00:01C29618] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gARDMgv25152 Subject: [NSIS] Interim Meeting Query Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, As both previous IETF meetings (54 & 55) have been quite busy, there is a possibility for an interim meeting before IETF 56. IETF 56 is March 16-21, 2003 - so early February may very well be the best time frame for a meeting. I discussed the possibilites with our ADs and Allison suggest she might be able to host it in New Jersey, which might be preferable as it is in between those on the West Coast and those in Europe. Topics to discuss would be: 1) Framework document 2) Analysis document 3) 2 layer functionality split 4) Settling the existing security docs Is anyone interested in this? Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 08:26: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 IAA08683 for ; Wed, 27 Nov 2002 08:26:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARDSji25413 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 08:28: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 gARDShv25390; Wed, 27 Nov 2002 08:28: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 gARDNav25185 for ; Wed, 27 Nov 2002 08:23:36 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08600 for ; Wed, 27 Nov 2002 08:20:50 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gARDOX621800 for ; Wed, 27 Nov 2002 15:24:33 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Nov 2002 15:23:33 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Nov 2002 15:23:32 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Nov 2002 15:23:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Updated Charter Date: Wed, 27 Nov 2002 15:23:31 +0200 Message-ID: Thread-Topic: [NSIS] Updated Charter Thread-Index: AcKRqtrHV/Lk+0xpQFSJJJmXBdT31gEbTsoA To: Cc: X-OriginalArrivalTime: 27 Nov 2002 13:23:32.0744 (UTC) FILETIME=[2EBEE880:01C29618] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gARDNav25186 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Bob, > Mind you, maybe the Routing area should investigate whether there is > room in the global routing architecture for some form of local fixups > using some form of signaling. I am not a routing expert so this is > only a wild idea. But that would surely have to be founded on a firm > base of research in the routing area, and it must be totally out of > scope for NSIS. Have friends in the Routing area, or would this be a nice thing to ship to the IRTF Routing Research Group? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 09:15:49 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 JAA10542 for ; Wed, 27 Nov 2002 09:15:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAREI4o28591 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 09:18: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 gAREHwv28559; Wed, 27 Nov 2002 09:17: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 gAREEbv28401 for ; Wed, 27 Nov 2002 09:14:37 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10309 for ; Wed, 27 Nov 2002 09:11:51 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gAREEL131765; Wed, 27 Nov 2002 15:14:21 +0100 Subject: RE: [NSIS] Updated Charter To: Bob Braden Cc: braden@ISI.EDU, john.loughney@nokia.com, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 27 Nov 2002 15:14:17 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/27/2002 15:14:21 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Bob, Would it be correct to describe the idea you mention below as 'a signalling protocol that allows a signalling path to locally diverge from the data path provided both paths branch and merge in the same domain (or any region under the same administration)'. This would in fact mend local 'funny' routing practices. However, another issue addressed in RFC 2998 is: 'The assumption within both IntServ and DiffServ architectures is that the best effort routing path is used, where the path is either capable of sustaining the service load, or not. Assuming that the deployment of service differentiating infrastructure will be piecemeal, even if only in the initial stages of a QoS rollout, such an assumption may be unwarranted.' I interpret this statement as a need to be able to separate routing contexts for different service classes, e.g. because the normal L3 AS next hop only delivers BE service. I am not sure if this can be provided with only local divergence from the BE routing path. What do you think? Sven. Bob Braden @ietf.org on 21/11/2002 23:10:47 Sent by: nsis-admin@ietf.org To: braden@ISI.EDU, john.loughney@nokia.com cc: nsis@ietf.org Subject: RE: [NSIS] Updated Charter John, *> Yes, the transport layer should be aware of some of these issues, *> but we should be careful that we don't create an overlay network *> which we are routing the signaling messages on. If we do, then *> we can very easily have divergence of the signaling path from *> the data path. (... among other evils) Mind you, maybe the Routing area should investigate whether there is room in the global routing architecture for some form of local fixups using some form of signaling. I am not a routing expert so this is only a wild idea. But that would surely have to be founded on a firm base of research in the routing area, and it must be totally out of scope for NSIS. Bob *> *> best regards, *> John *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 09:21: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 JAA10840 for ; Wed, 27 Nov 2002 09:21:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARENLo28942 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 09:23:21 -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 gARENJv28934; Wed, 27 Nov 2002 09:23: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 gARELwv28858 for ; Wed, 27 Nov 2002 09:21:58 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10772 for ; Wed, 27 Nov 2002 09:19:11 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gARELlg02028; Wed, 27 Nov 2002 15:21:47 +0100 Subject: RE: [NSIS] Updated Charter To: sven.van_den_bosch@alcatel.be Cc: Bob Braden , braden@ISI.EDU, john.loughney@nokia.com, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 27 Nov 2002 15:21:43 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/27/2002 15:21:47 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , The reference below should be to RFC 2990. Sorry, Sven. Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL@ietf.org on 27/11/2002 15:14:17 Sent by: nsis-admin@ietf.org To: Bob Braden cc: braden@ISI.EDU, john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] Updated Charter Hi Bob, Would it be correct to describe the idea you mention below as 'a signalling protocol that allows a signalling path to locally diverge from the data path provided both paths branch and merge in the same domain (or any region under the same administration)'. This would in fact mend local 'funny' routing practices. However, another issue addressed in RFC 2998 is: 'The assumption within both IntServ and DiffServ architectures is that the best effort routing path is used, where the path is either capable of sustaining the service load, or not. Assuming that the deployment of service differentiating infrastructure will be piecemeal, even if only in the initial stages of a QoS rollout, such an assumption may be unwarranted.' I interpret this statement as a need to be able to separate routing contexts for different service classes, e.g. because the normal L3 AS next hop only delivers BE service. I am not sure if this can be provided with only local divergence from the BE routing path. What do you think? Sven. Bob Braden @ietf.org on 21/11/2002 23:10:47 Sent by: nsis-admin@ietf.org To: braden@ISI.EDU, john.loughney@nokia.com cc: nsis@ietf.org Subject: RE: [NSIS] Updated Charter John, *> Yes, the transport layer should be aware of some of these issues, *> but we should be careful that we don't create an overlay network *> which we are routing the signaling messages on. If we do, then *> we can very easily have divergence of the signaling path from *> the data path. (... among other evils) Mind you, maybe the Routing area should investigate whether there is room in the global routing architecture for some form of local fixups using some form of signaling. I am not a routing expert so this is only a wild idea. But that would surely have to be founded on a firm base of research in the routing area, and it must be totally out of scope for NSIS. Bob *> *> best regards, *> John *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 10:24: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 KAA14383 for ; Wed, 27 Nov 2002 10:24:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARFQW400953 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 10:26: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 gARFQSv00904; Wed, 27 Nov 2002 10:26: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 gARFNxv00788 for ; Wed, 27 Nov 2002 10:23:59 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14234 for ; Wed, 27 Nov 2002 10:21:11 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id gARFNs600434; Wed, 27 Nov 2002 16:23:54 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id gARFNsC29091; Wed, 27 Nov 2002 16:23:54 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Kuntal Chowdhury" , Subject: RE: [NSIS] next peer issue in rsvp-sec Date: Wed, 27 Nov 2002 16:24:42 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02F2_01C29631.7DBE1B90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <23BDB0046F3ED51185CD0002A5608D240706E661@zrc2c009.us.nortel.com> Importance: Normal Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_02F2_01C29631.7DBE1B90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit next peer issue in rsvp-sechi Kuntal the intention of this slide was to illustrate that the rsvp path message is (with some modification) also a means to provide next-peer discovery. if you already know the next peer then you might be able to use the correct security association (and therefore the key). additionally a problem is the fact that a router must allows expect to receive a error message from somewhere indicating that a security verification failure occurred. without knowning the topology you cannot even restrict the nodes where these error messages have to come from. ciao hannes -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Kuntal Chowdhury Sent: Tuesday, November 26, 2002 6:55 PM To: nsis@ietf.org Subject: [NSIS] next peer issue in rsvp-sec Hi all, I think the Next Peer issue highlighted in the RSVP Security Properties slide (http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Properties.ppt) can be solved by adding an ERO (EXPLICIT_ROUTE object) in the RSVP-PATH message. Of course the intervening network needs to understand ERO. -Kuntal ------=_NextPart_000_02F2_01C29631.7DBE1B90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable next peer issue in rsvp-sec
hi=20 Kuntal=20
 
the=20 intention of this slide was to illustrate that the rsvp path message is = (with=20 some modification) also a means to provide next-peer discovery.=20
 
if you=20 already know the next peer then you might be able to use the correct = security=20 association (and therefore the key).
 
additionally a problem is the fact that a router must allows = expect to=20 receive a error message from somewhere indicating that a security = verification=20 failure occurred. without knowning the topology you cannot even restrict = the=20 nodes where these error messages have to come from.
 
ciao
hannes
 
-----Original Message-----
From: = nsis-admin@ietf.org=20 [mailto:nsis-admin@ietf.org]On Behalf Of Kuntal=20 Chowdhury
Sent: Tuesday, November 26, 2002 6:55 = PM
To:=20 nsis@ietf.org
Subject: [NSIS] next peer issue in=20 rsvp-sec

Hi all,
I think the Next = Peer issue=20 highlighted in the RSVP Security Properties slide
(http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Pr= operties.ppt)=20
can be solved by adding an ERO = (EXPLICIT_ROUTE object)=20 in the RSVP-PATH message.
Of course the = intervening=20 network needs to understand ERO.

-Kuntal

------=_NextPart_000_02F2_01C29631.7DBE1B90-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 10:24: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 KAA14389 for ; Wed, 27 Nov 2002 10:24:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARFQWl00965 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 10:26: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 gARFQTv00919; Wed, 27 Nov 2002 10:26:29 -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 gARFNxv00792 for ; Wed, 27 Nov 2002 10:23:59 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14236 for ; Wed, 27 Nov 2002 10:21:12 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gARFNtj15347; Wed, 27 Nov 2002 16:23:55 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id gARFNsC29094; Wed, 27 Nov 2002 16:23:55 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Ping Pan" , Cc: "Hancock, Robert" , "Kuntal Chowdhury" , Subject: RE: [NSIS] next peer issue in rsvp-sec Date: Wed, 27 Nov 2002 16:24:42 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3DE48607.2090908@cs.columbia.edu> Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi ping referring to the security of rsvp-te and mpls in particular is unfortunately not very helpful. the way rsvp-te (and mpls) works is different to rsvp (or a generic signaling protocol) in general. hence you could basically use anything and it would work (in the worst case you can blame the administrator for a bad network configuration). i would argue that in case of interdomain signaling everything is much easier compared to end-to-end. i bet that there are a few people who believe that you do not need to secure intra-domain signaling messages. i, however, think that there is a deployment problem for rsvp since you cannot assume that every router is an rsvp aware. (and we want to skip the policy issues, the missing key management and other things for the moment). hence i believe that the issues raised here are not only imagination. consider a case where rsvp signaling messages are interpreted only at the access networks and are treated transparently in the core network (because of overprovisioning, diffserv clouds, etc.). would you as an access network service provider be willing to make a qos reservation or some processig without having these signaling message to be properly secured? sender-initiated messages and proxy operation would make the situation more difficult. i have two questions regarding igp: - how are messages delivered between two nodes? (transport protocol/addressing) - how does one node learn to which other node to send the message? (discovery mechanism) ciao hannes > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Ping > Pan > Sent: Wednesday, November 27, 2002 9:45 AM > To: sven.van_den_bosch@alcatel.be > Cc: Hancock, Robert; Kuntal Chowdhury; nsis@ietf.org > Subject: Re: [NSIS] next peer issue in rsvp-sec > > > I thought ERO was invented for traffic engineering. Why is it relevant > to security? > > This entire RSVP security thread sounds fishy to me. RSVP is no > different than IGP, where control messages are passed hop-by-hop. If > people are happy with how routing protocols are handling with their > security issues (MD5 and what not), then RSVP should just adapt the same > mechanism. I know some people are not happy with routing security in the > first place, then maybe this entire protocol security issue should be > considered else where. > > Finally, I am just curious about where this NSIS protocol would get > deployed to have this security problem. In the backbone, RSVP-TE seems > to be fine as it is. I wonder if this is designed for mobile users. > > Thanks! > > - Ping > > > sven.van_den_bosch@alcatel.be wrote: > > Hi Robert, Kuntal, all, > > > > I interpreted the ERO comment as follows: The fact that the security > > association is now wrong results from the route change. The ERO > is a way to > > pin the route to what it originally was and thus prevents the > route change. > > This means that the security association will be the correct > one. What do > > you think? > > > > Cheers, > > Sven. > > > > > > > > > > > > "Hancock, Robert" @ietf.org on 27/11/2002 > > 00:50:26 > > > > Sent by: nsis-admin@ietf.org > > > > > > To: Kuntal Chowdhury , nsis@ietf.org > > cc: > > Subject: RE: [NSIS] next peer issue in rsvp-sec > > > > > > > > Hi, > > > > I don't believe that the ERO is relevant here. The issue isn't that the > > messages get sent to the wrong next peer (which the ERO would > fix, albeit > > in a somewhat overweight way), it's that they are sent to the > right next > > peer, but with the wrong security association, because the source didn't > > know the next peer had changed. So this is essentially an > issue of how to > > discover and react to route changes. (At least I think so.) > > > > Cheers, > > > > Robert H. > > -----Original Message----- > > From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] > > Sent: 26 November 2002 17:55 > > To: nsis@ietf.org > > Subject: [NSIS] next peer issue in rsvp-sec > > > > > > > > Hi all, > > I think the Next Peer issue highlighted in the RSVP Security Properties > > slide > > (http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Properties.ppt) > > can be solved by adding an ERO (EXPLICIT_ROUTE object) in the RSVP-PATH > > message. > > Of course the intervening network needs to understand ERO. > > > > -Kuntal > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 11:28: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 LAA17376 for ; Wed, 27 Nov 2002 11:28:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARGUdE05447 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 11:30:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARGUVv05387; Wed, 27 Nov 2002 11:30: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 gARGOjv05018 for ; Wed, 27 Nov 2002 11:24:45 -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 LAA17162 for ; Wed, 27 Nov 2002 11:21: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 gARGOgY43807; Wed, 27 Nov 2002 17:24:42 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 5E17F79F37; Wed, 27 Nov 2002 17:23:02 +0100 (CET) Date: Wed, 27 Nov 2002 17:23:02 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] Interim Meeting Query Message-ID: <9704954.1038417782@[192.168.102.207]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (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: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit John, I think we should be able to sort out the issues on the mailing list. The 2 layer split is IMO the only topic face-to-face is benefical. And if you plan an interim Januarry would be better such that editors are able to push out a new document for the IETF meeting. Marcus --On Mittwoch, 27. November 2002 15:22 +0200 john.loughney@nokia.com wrote: > Hi all, > > As both previous IETF meetings (54 & 55) have been quite busy, there is a > possibility for an interim meeting before IETF 56. IETF 56 is March > 16-21, 2003 - so early February may very well be the best time frame for > a meeting. I discussed the possibilites with our ADs and Allison suggest > she might be able to host it in New Jersey, which might be preferable as > it is in between those on the West Coast and those in Europe. > > Topics to discuss would be: > > 1) Framework document > 2) Analysis document > 3) 2 layer functionality split > 4) Settling the existing security docs > > Is anyone interested in this? > > Thanks, > John > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 11:31:50 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 LAA17656 for ; Wed, 27 Nov 2002 11:31:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARGY7m05762 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 11:34: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 gARGY4v05755; Wed, 27 Nov 2002 11:34: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 gARGXiv05703 for ; Wed, 27 Nov 2002 11:33:44 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17562 for ; Wed, 27 Nov 2002 11:30:56 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gARGXcB25367; Wed, 27 Nov 2002 08:33:38 -0800 (PST) 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 gARGXn322952; Wed, 27 Nov 2002 10:33:50 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Nov 2002 10:33:37 -0600 Message-ID: <23BDB0046F3ED51185CD0002A5608D240706F05E@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: "Hancock, Robert" , nsis@ietf.org Subject: RE: [NSIS] next peer issue in rsvp-sec Date: Wed, 27 Nov 2002 10:33:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29632.BB03E100" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling 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_01C29632.BB03E100 Content-Type: text/plain Hi Robert, I think the statement "source didn't know the next peer had changed" means the plain IP routing protocol did not propagate topology change (a non converged network). Alternatively the "source routing" algorithm (that computes the explicit route) did not do a good job. However these error scenarios in explicit route computation do not mean that a correctly formed ERO (with correct topology) information cannot be used in securing signaling exchanges with the next peers. -Kuntal -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: Tuesday, November 26, 2002 5:50 PM To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; nsis@ietf.org Subject: RE: [NSIS] next peer issue in rsvp-sec Hi, I don't believe that the ERO is relevant here. The issue isn't that the messages get sent to the wrong next peer (which the ERO would fix, albeit in a somewhat overweight way), it's that they are sent to the right next peer, but with the wrong security association, because the source didn't know the next peer had changed. So this is essentially an issue of how to discover and react to route changes. (At least I think so.) Cheers, Robert H. -----Original Message----- From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] Sent: 26 November 2002 17:55 To: nsis@ietf.org Subject: [NSIS] next peer issue in rsvp-sec Hi all, I think the Next Peer issue highlighted in the RSVP Security Properties slide (http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Properties.ppt ) can be solved by adding an ERO (EXPLICIT_ROUTE object) in the RSVP-PATH message. Of course the intervening network needs to understand ERO. -Kuntal ------_=_NextPart_001_01C29632.BB03E100 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
Hi=20 Robert,
I=20 think the statement "source didn't know the next peer had changed" = means the=20 plain IP routing protocol did not propagate topology change (a non = converged=20 network). Alternatively the "source routing" algorithm (that computes = the=20 explicit route) did not do a good job. However these error scenarios in = explicit=20 route computation do not mean that a correctly formed ERO (with correct = topology) information cannot be used in securing signaling exchanges = with the=20 next peers.
 
-Kuntal
 
-----Original Message-----
From: = Hancock, Robert=20 [mailto:robert.hancock@roke.co.uk]
Sent: Tuesday, November = 26, 2002=20 5:50 PM
To: Chowdhury, Kuntal [RICH1:2H18:EXCH];=20 nsis@ietf.org
Subject: RE: [NSIS] next peer issue in=20 rsvp-sec

Hi,
 
I=20 don't believe that the ERO is relevant here. The issue isn't that the = messages=20 get sent to the wrong next peer (which the ERO would fix, albeit in=20 a somewhat overweight way), it's that they are sent to the = right=20 next peer, but with the wrong security association, because the = source didn't=20 know the next peer had changed. So this is essentially an issue of = how to=20 discover and react to route changes. (At least I think=20 so.)
 
Cheers,
 
Robert H.
-----Original Message-----
From: Kuntal = Chowdhury=20 [mailto:chowdury@nortelnetworks.com]
Sent: 26 November = 2002=20 17:55
To: nsis@ietf.org
Subject: [NSIS] next = peer issue=20 in rsvp-sec

Hi all,
I think the = Next Peer issue=20 highlighted in the RSVP Security Properties slide
(http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Properties= .ppt)=20
can be solved by adding an ERO = (EXPLICIT_ROUTE=20 object) in the RSVP-PATH message.
Of = course the=20 intervening network needs to understand ERO.

-Kuntal =

------_=_NextPart_001_01C29632.BB03E100-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 11:58: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 LAA18990 for ; Wed, 27 Nov 2002 11:58:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARH0bO08139 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 12:00: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 gARH0Sv08131; Wed, 27 Nov 2002 12:00: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 gARGx1v08041 for ; Wed, 27 Nov 2002 11:59:01 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18934 for ; Wed, 27 Nov 2002 11:56:13 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gARGwL919096 for ; Wed, 27 Nov 2002 18:58:21 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Nov 2002 18:58:56 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Nov 2002 18:58:56 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Nov 2002 18:58:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 27 Nov 2002 18:58:55 +0200 Message-ID: Thread-Topic: [NSIS] Updated Charter Thread-Index: AcKTxFZKU5BROJlmQLiQV5SFlj/dhACcWJwA To: X-OriginalArrivalTime: 27 Nov 2002 16:58:56.0450 (UTC) FILETIME=[45DFF220:01C29636] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gARGx1v08042 Subject: [NSIS] Use IPSec draft Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, Regarding recent security discussion, one of the Security ADs suggest the following draft, as input to the discussion: http://www.ietf.org/internet-drafts/draft-bellovin-useipsec-00.txt It is a good read and useful background for our security discussions. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 12:12: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 MAA19694 for ; Wed, 27 Nov 2002 12:12:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARHEh109968 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 12:14: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 gARHEbv09876; Wed, 27 Nov 2002 12:14: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 gARH91v09355 for ; Wed, 27 Nov 2002 12:09:01 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19349 for ; Wed, 27 Nov 2002 12:06:12 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gARH8sB19339; Wed, 27 Nov 2002 09:08:55 -0800 (PST) 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 gARH96316561; Wed, 27 Nov 2002 11:09:07 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Nov 2002 11:08:54 -0600 Message-ID: <23BDB0046F3ED51185CD0002A5608D240706F101@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: Hannes.Tschofenig@siemens.com, nsis@ietf.org Subject: RE: [NSIS] next peer issue in rsvp-sec Date: Wed, 27 Nov 2002 11:08:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29637.A9E833D0" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling 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_01C29637.A9E833D0 Content-Type: text/plain Hi Hannes, I agree that the router that sends the PATH message, should be prepared to accept occasional error messages from peer's if for some reason the PATH message did not get routed to the intended peer. The point I was trying to make was: the chances of routing the PATH message (with proper security association with an indented peer) will be higher if route pinning (e.g. ERO) is used. -Kuntal -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@siemens.com] Sent: Wednesday, November 27, 2002 9:25 AM To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; nsis@ietf.org Subject: RE: [NSIS] next peer issue in rsvp-sec hi Kuntal the intention of this slide was to illustrate that the rsvp path message is (with some modification) also a means to provide next-peer discovery. if you already know the next peer then you might be able to use the correct security association (and therefore the key). additionally a problem is the fact that a router must allows expect to receive a error message from somewhere indicating that a security verification failure occurred. without knowning the topology you cannot even restrict the nodes where these error messages have to come from. ciao hannes -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Kuntal Chowdhury Sent: Tuesday, November 26, 2002 6:55 PM To: nsis@ietf.org Subject: [NSIS] next peer issue in rsvp-sec Hi all, I think the Next Peer issue highlighted in the RSVP Security Properties slide (http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Properties.ppt ) can be solved by adding an ERO (EXPLICIT_ROUTE object) in the RSVP-PATH message. Of course the intervening network needs to understand ERO. -Kuntal ------_=_NextPart_001_01C29637.A9E833D0 Content-Type: text/html Message
Hi Hannes,
I agree that the router that sends the PATH message, should be prepared to accept occasional error messages from peer's if for some reason the PATH message did not get routed to the intended peer.
The point I was trying to make was: the chances of routing the PATH message (with proper security association with an indented peer) will be higher if route pinning (e.g. ERO) is used.
 
-Kuntal
 
-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@siemens.com]
Sent: Wednesday, November 27, 2002 9:25 AM
To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; nsis@ietf.org
Subject: RE: [NSIS] next peer issue in rsvp-sec

hi Kuntal
 
the intention of this slide was to illustrate that the rsvp path message is (with some modification) also a means to provide next-peer discovery.
 
if you already know the next peer then you might be able to use the correct security association (and therefore the key).
 
additionally a problem is the fact that a router must allows expect to receive a error message from somewhere indicating that a security verification failure occurred. without knowning the topology you cannot even restrict the nodes where these error messages have to come from.
 
ciao
hannes
 
-----Original Message-----
From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Kuntal Chowdhury
Sent: Tuesday, November 26, 2002 6:55 PM
To: nsis@ietf.org
Subject: [NSIS] next peer issue in rsvp-sec

Hi all,
I think the Next Peer issue highlighted in the RSVP Security Properties slide
(http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Properties.ppt)
can be solved by adding an ERO (EXPLICIT_ROUTE object) in the RSVP-PATH message.
Of course the intervening network needs to understand ERO.

-Kuntal

------_=_NextPart_001_01C29637.A9E833D0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 12:28: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 LAA17375 for ; Wed, 27 Nov 2002 11:28:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARGUdN05437 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 11:30:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARGUZv05426; Wed, 27 Nov 2002 11:30:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARGPqv05079 for ; Wed, 27 Nov 2002 11:25:52 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17186 for ; Wed, 27 Nov 2002 11:23:04 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gARGPC929719 for ; Wed, 27 Nov 2002 18:25:12 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Nov 2002 18:25:48 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Nov 2002 18:25:47 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Nov 2002 18:25:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Interim Meeting Query Date: Wed, 27 Nov 2002 18:25:46 +0200 Message-ID: Thread-Topic: [NSIS] Interim Meeting Query Thread-Index: AcKWMX/CHR0qU1kiS3eOQm+Q0QbnzgAAApKQ To: , X-OriginalArrivalTime: 27 Nov 2002 16:25:46.0833 (UTC) FILETIME=[A3F87C10:01C29631] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gARGPqv05080 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Marcus, > I think we should be able to sort out the issues on the mailing list. The 2 > layer split is IMO the only topic face-to-face is benefical. I agree, I was thinking of having limited time on the other areas. > And if you plan an interim Januarry would be better such that editors are > able to push out a new document for the IETF meeting. Late January is OK with me as well. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 15:34: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 PAA27046 for ; Wed, 27 Nov 2002 15:34:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARKaY222834 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 15:36: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 gARKaVv22823; Wed, 27 Nov 2002 15:36: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 gARKZBv22757 for ; Wed, 27 Nov 2002 15:35:11 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26990 for ; Wed, 27 Nov 2002 15:32:21 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Nov 2002 20:35:03 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF6034@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Date: Wed, 27 Nov 2002 20:35:01 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] attempted summary of next-peer issue (was: RE: next peer issue in rsvp-sec) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Kuntal, Sven, Ping, Michael, John, Melinda, Hannes, all, It seems a number of issues have got combined here. Here is an attempted summary. Let me know if I missed or confused something. 1. If the originator knows the route the traffic is taking up to the next peer, it can send the signalling message to the right place no problem - there is *no next-peer issue* in this case. (This could be either because the originator is doing traffic engineering, or has complete IGP knowledge, or is telepathic, or whatever.) It can send the signalling message with an ERO object or with what the framework (currently) calls peer-peer addressing; in any case, there is *no problem*. 2. If you are in the fortunate position of knowing all nodes are NSIS-signalling capable, there is also *no next-peer issue* in this case. This is analogous to the IGP case. You know the signalling peer just by knowing the outgoing IP neighbour. 3. I believe we the NSIS w.g. are also (indeed, primarily???) interested in situations where (a) you are not traffic engineering or route pinning or assuming routing awareness, and (b) NTLP or indeed NSLP peers are far apart in IP terms. This is where the next-peer issue arises. And where, as Hannes points out, you also need to worry about the patherr messages in the other direction posing a security threat. [that's why you need security specialists - they always give the threat knife that one extra twist...] Is this accurate? Robert H. > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@siemens.com] > Sent: 27 November 2002 15:25 > To: Ping Pan; sven.van_den_bosch@alcatel.be > Cc: Hancock, Robert; Kuntal Chowdhury; nsis@ietf.org > Subject: RE: [NSIS] next peer issue in rsvp-sec > > > hi ping > > referring to the security of rsvp-te and mpls in particular > is unfortunately > not very helpful. the way rsvp-te (and mpls) works is > different to rsvp (or > a generic signaling protocol) in general. hence you could > basically use > anything and it would work (in the worst case you can blame the > administrator for a bad network configuration). i would argue > that in case > of interdomain signaling everything is much easier compared > to end-to-end. i > bet that there are a few people who believe that you do not > need to secure > intra-domain signaling messages. > > i, however, think that there is a deployment problem for rsvp > since you > cannot assume that every router is an rsvp aware. (and we > want to skip the > policy issues, the missing key management and other things > for the moment). > hence i believe that the issues raised here are not only imagination. > > consider a case where rsvp signaling messages are interpreted > only at the > access networks and are treated transparently in the core > network (because > of overprovisioning, diffserv clouds, etc.). would you as an > access network > service provider be willing to make a qos reservation or some > processig > without having these signaling message to be properly secured? > sender-initiated messages and proxy operation would make the > situation more > difficult. > > i have two questions regarding igp: > > - how are messages delivered between two nodes? (transport > protocol/addressing) > - how does one node learn to which other node to send the message? > (discovery mechanism) > > ciao > hannes > > > > -----Original Message----- > > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On > Behalf Of Ping > > Pan > > Sent: Wednesday, November 27, 2002 9:45 AM > > To: sven.van_den_bosch@alcatel.be > > Cc: Hancock, Robert; Kuntal Chowdhury; nsis@ietf.org > > Subject: Re: [NSIS] next peer issue in rsvp-sec > > > > > > I thought ERO was invented for traffic engineering. Why is > it relevant > > to security? > > > > This entire RSVP security thread sounds fishy to me. RSVP is no > > different than IGP, where control messages are passed hop-by-hop. If > > people are happy with how routing protocols are handling with their > > security issues (MD5 and what not), then RSVP should just > adapt the same > > mechanism. I know some people are not happy with routing > security in the > > first place, then maybe this entire protocol security issue > should be > > considered else where. > > > > Finally, I am just curious about where this NSIS protocol would get > > deployed to have this security problem. In the backbone, > RSVP-TE seems > > to be fine as it is. I wonder if this is designed for mobile users. > > > > Thanks! > > > > - Ping > > > > > > sven.van_den_bosch@alcatel.be wrote: > > > Hi Robert, Kuntal, all, > > > > > > I interpreted the ERO comment as follows: The fact that > the security > > > association is now wrong results from the route change. The ERO > > is a way to > > > pin the route to what it originally was and thus prevents the > > route change. > > > This means that the security association will be the correct > > one. What do > > > you think? > > > > > > Cheers, > > > Sven. > > > > > > > > > > > > > > > > > > "Hancock, Robert" @ietf.org on > 27/11/2002 > > > 00:50:26 > > > > > > Sent by: nsis-admin@ietf.org > > > > > > > > > To: Kuntal Chowdhury , > nsis@ietf.org > > > cc: > > > Subject: RE: [NSIS] next peer issue in rsvp-sec > > > > > > > > > > > > Hi, > > > > > > I don't believe that the ERO is relevant here. The issue > isn't that the > > > messages get sent to the wrong next peer (which the ERO would > > fix, albeit > > > in a somewhat overweight way), it's that they are sent to the > > right next > > > peer, but with the wrong security association, because > the source didn't > > > know the next peer had changed. So this is essentially an > > issue of how to > > > discover and react to route changes. (At least I think so.) > > > > > > Cheers, > > > > > > Robert H. > > > -----Original Message----- > > > From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] > > > Sent: 26 November 2002 17:55 > > > To: nsis@ietf.org > > > Subject: [NSIS] next peer issue in rsvp-sec > > > > > > > > > > > > Hi all, > > > I think the Next Peer issue highlighted in the RSVP > Security Properties > > > slide > > > > (http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Proper ties.ppt) > > can be solved by adding an ERO (EXPLICIT_ROUTE object) in the RSVP-PATH > > message. > > Of course the intervening network needs to understand ERO. > > > > -Kuntal > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 15:34: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 PAA27059 for ; Wed, 27 Nov 2002 15:34:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARKak522877 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 15:36: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 gARKacv22853; Wed, 27 Nov 2002 15:36: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 gARKZLv22763 for ; Wed, 27 Nov 2002 15:35:21 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26994 for ; Wed, 27 Nov 2002 15:32:31 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Nov 2002 20:35:13 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF6036@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Subject: RE: [NSIS] next peer issue in rsvp-sec Date: Wed, 27 Nov 2002 20:35:06 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , So, I'd like to check I understand the subtleties of the wording correctly: the NTLP needs to protect itself against threats against the transport (and I guess below), which we think of as things like DoS, some confidentiality aspects (traffic analysis), could be done with something channel-security-like? (or we think of just DoS protection, probably no cryptographic protection?) whereas an NSLP would have application specific protection of elements of the payload (integrity protection and authorisation aspects)? This would certainly seem reasonable to me and was my working assumption going into Atlanta (at least up to the point where Melinda very reasonably pointed out we should have a clearer picture of the NTLP functionality before deciding its security requirements...) However, I don't think the layer split tells us anything about how technically to address the next-peer issue we started with. Robert H. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 27 November 2002 13:15 > To: mshore@cisco.com > Cc: mat@cisco.com; nsis@ietf.org > Subject: RE: [NSIS] next peer issue in rsvp-sec > > > Hi Melinda, > > Your wordsmithing works for me. > > John > > > -----Original Message----- > > From: ext Melinda Shore [mailto:mshore@cisco.com] > > Sent: 27 November, 2002 15:09 > > To: Loughney John (NRC/Helsinki) > > Cc: mat@cisco.com; nsis@ietf.org > > Subject: Re: [NSIS] next peer issue in rsvp-sec > > > > > > > So, I think that part of the 2 layer functional split > > > that we need to work on should try to address this. > > > I prefer to have the upper layer handle the authentication > > > and payload encryption part. > > > > I'd swap some words around and to say "upper layer handle > > the payload authentication and encryption part." Basically > > all we're saying is that the application needs to protect > > itself against threats against the application and that the > > transport layer needs to protect itself against threats > > against the transport. > > > > Melinda > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 15:34: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 PAA27072 for ; Wed, 27 Nov 2002 15:34:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARKalX22889 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 15:36: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 gARKaiv22868; Wed, 27 Nov 2002 15:36: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 gARKZLv22765 for ; Wed, 27 Nov 2002 15:35:21 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26995 for ; Wed, 27 Nov 2002 15:32:31 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Nov 2002 20:35:13 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF6037@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Subject: RE: [NSIS] Use IPSec draft Date: Wed, 27 Nov 2002 20:35:07 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi, I like this draft also, especially the warning in section 2 ("If IPsec is a bad choice, use another standardized, well-understood security protocol. Don't roll your own.") Personally, I feel the security problems for general path-coupled signalling taken as a whole are sufficiently weird that it's worth considering how to slice the problem up at the architectural stage to get a better match to existing "standardized, well-understood security protocol[s]". But I know other people object to this style of approach. Robert H. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 27 November 2002 16:59 > To: nsis@ietf.org > Subject: [NSIS] Use IPSec draft > > > Hi all, > > Regarding recent security discussion, one of the Security ADs > suggest the > following draft, as input to the discussion: > > http://www.ietf.org/internet-drafts/draft-bellovin-useipsec-00.txt > > It is a good read and useful background for our security discussions. > > thanks, > John > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 15:59: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 PAA27716 for ; Wed, 27 Nov 2002 15:59:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARL1ag24398 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 16:01: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 gARL1Cv24391; Wed, 27 Nov 2002 16:01: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 gARL0Xv24356 for ; Wed, 27 Nov 2002 16:00:33 -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 PAA27642 for ; Wed, 27 Nov 2002 15:57:43 -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 gARL0N0R017589; Wed, 27 Nov 2002 13:00:23 -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 ABA44369; Wed, 27 Nov 2002 13:00:26 -0800 (PST) Message-Id: <200211272100.ABA44369@mira-sjc5-c.cisco.com> To: "Hancock, Robert" cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] next peer issue in rsvp-sec In-Reply-To: Message from "Hancock, Robert" of "Wed, 27 Nov 2002 20:35:06 GMT." <76C92FBBFB58D411AE760090271ED41805DF6036@rsys002a.roke.co.uk> Date: Wed, 27 Nov 2002 16:00:26 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , I really don't think that at this point we need anything more elaborate than a recognition that the security functions used in each layer must be appropriate to that layer, and that the application's issues are certainly going to be different from those of the transport protocol. The requirements and framework don't have to be enormously detailed. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 17:12:00 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 RAA29819 for ; Wed, 27 Nov 2002 17:12:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARMEKC29290 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 17:14: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 gARMEDv29278; Wed, 27 Nov 2002 17:14: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 gARMD7v29253 for ; Wed, 27 Nov 2002 17:13:07 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29746 for ; Wed, 27 Nov 2002 17:10:14 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gARMCvB17902; Wed, 27 Nov 2002 14:12:57 -0800 (PST) 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 gARMD9310660; Wed, 27 Nov 2002 16:13:09 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Nov 2002 16:12:56 -0600 Message-ID: <23BDB0046F3ED51185CD0002A5608D24070BA1ED@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: "Hancock, Robert" , nsis@ietf.org Subject: RE: [NSIS] attempted summary of next-peer issue (was: RE: next pe er issue in rsvp-sec) Date: Wed, 27 Nov 2002 16:12:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29662.225C7040" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling 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_01C29662.225C7040 Content-Type: text/plain Hi Robert, I think point 3 is important to note. I don't see anything in the w.g. charter that says "explicit route" capability is beyond the scope of NSIS. Section 4.1, assumption 5 and 6 in draft-ietf-nsis-req-05.txt has some relevant texts on this subject: " 5. We assume that there are means for the discovery of NSIS entities in order to know the signaling peers (solutions include static configuration, automatically discovered, or implicitly runs over the right nodes, etc.) The discovery of the NSIS entities has security implications that need to be addressed properly. These implications largely depend on the chosen protocol. For some security mechanisms (i.e. Kerberos, pre-shared secret) it is required to know the identity of the other entity. Hence the discovery mechanism may provide means to learn this identity, which is then later used to retrieve the required keys and parameters. 6. NSIS assumes to operate with networks using standard ("normal") L3 routing. Where "normal" is not specified more exactly on purpose. " I think assumption 5 is unclear as what "automatic discovery" really means. However I think assumption 6 is (implicitly) in-line with your point 3. Although not explicitly mentioned in the nsis-req draft, I guess the general assumption in the w.g. is to only discuss issues with peers that are beyond reach of IGP and nodes that can only do plain IP routing. In short, no "explicit routing". Thanks for the summary. Regards, Kuntal > Hi Kuntal, Sven, Ping, Michael, John, Melinda, Hannes, all, > > It seems a number of issues have got combined here. Here is > an attempted summary. Let me know if I missed or confused something. > > 1. If the originator knows the route the traffic is taking up > to the next peer, it can send the signalling message to the > right place no problem - there is *no next-peer issue* in > this case. (This could be either because the originator is > doing traffic engineering, or has complete IGP knowledge, or > is telepathic, or whatever.) It can send the signalling > message with an ERO object or with what the framework > (currently) calls peer-peer addressing; in any case, there is > *no problem*. > > 2. If you are in the fortunate position of knowing all nodes > are NSIS-signalling capable, there is also *no next-peer > issue* in this case. This is analogous to the IGP case. You > know the signalling peer just by knowing the outgoing IP neighbour. > > 3. I believe we the NSIS w.g. are also (indeed, primarily???) > interested in situations where (a) you are not traffic > engineering or route pinning or assuming routing awareness, > and (b) NTLP or indeed NSLP peers are far apart in IP terms. > This is where the next-peer issue arises. And where, as > Hannes points out, you also need to worry about the patherr > messages in the other direction posing a security threat. > > [that's why you need security specialists - they always give > the threat knife that one extra twist...] > > Is this accurate? > > Robert H. > > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@siemens.com] > > Sent: 27 November 2002 15:25 > > To: Ping Pan; sven.van_den_bosch@alcatel.be > > Cc: Hancock, Robert; Kuntal Chowdhury; nsis@ietf.org > > Subject: RE: [NSIS] next peer issue in rsvp-sec > > > > > > hi ping > > > > referring to the security of rsvp-te and mpls in particular > > is unfortunately > > not very helpful. the way rsvp-te (and mpls) works is > > different to rsvp (or > > a generic signaling protocol) in general. hence you could > > basically use > > anything and it would work (in the worst case you can blame the > > administrator for a bad network configuration). i would argue > > that in case > > of interdomain signaling everything is much easier compared > > to end-to-end. i > > bet that there are a few people who believe that you do not > > need to secure > > intra-domain signaling messages. > > > > i, however, think that there is a deployment problem for rsvp > > since you > > cannot assume that every router is an rsvp aware. (and we > > want to skip the > > policy issues, the missing key management and other things > > for the moment). > > hence i believe that the issues raised here are not only > imagination. > > > > consider a case where rsvp signaling messages are interpreted > > only at the > > access networks and are treated transparently in the core > > network (because > > of overprovisioning, diffserv clouds, etc.). would you as an > > access network > > service provider be willing to make a qos reservation or some > > processig > > without having these signaling message to be properly secured? > > sender-initiated messages and proxy operation would make the > > situation more > > difficult. > > > > i have two questions regarding igp: > > > > - how are messages delivered between two nodes? (transport > > protocol/addressing) > > - how does one node learn to which other node to send the message? > > (discovery mechanism) > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On > > Behalf Of Ping > > > Pan > > > Sent: Wednesday, November 27, 2002 9:45 AM > > > To: sven.van_den_bosch@alcatel.be > > > Cc: Hancock, Robert; Kuntal Chowdhury; nsis@ietf.org > > > Subject: Re: [NSIS] next peer issue in rsvp-sec > > > > > > > > > I thought ERO was invented for traffic engineering. Why is > > it relevant > > > to security? > > > > > > This entire RSVP security thread sounds fishy to me. RSVP is no > > > different than IGP, where control messages are passed > hop-by-hop. If > > > people are happy with how routing protocols are handling > with their > > > security issues (MD5 and what not), then RSVP should just > > adapt the same > > > mechanism. I know some people are not happy with routing > > security in the > > > first place, then maybe this entire protocol security issue > > should be > > > considered else where. > > > > > > Finally, I am just curious about where this NSIS protocol > would get > > > deployed to have this security problem. In the backbone, > > RSVP-TE seems > > > to be fine as it is. I wonder if this is designed for > mobile users. > > > > > > Thanks! > > > > > > - Ping > > > > > > > > > sven.van_den_bosch@alcatel.be wrote: > > > > Hi Robert, Kuntal, all, > > > > > > > > I interpreted the ERO comment as follows: The fact that > > the security > > > > association is now wrong results from the route change. The ERO > > > is a way to > > > > pin the route to what it originally was and thus prevents the > > > route change. > > > > This means that the security association will be the correct > > > one. What do > > > > you think? > > > > > > > > Cheers, > > > > Sven. > > > > > > > > > > > > > > > > > > > > > > > > "Hancock, Robert" @ietf.org on > > 27/11/2002 > > > > 00:50:26 > > > > > > > > Sent by: nsis-admin@ietf.org > > > > > > > > > > > > To: Kuntal Chowdhury , > > nsis@ietf.org > > > > cc: > > > > Subject: RE: [NSIS] next peer issue in rsvp-sec > > > > > > > > > > > > > > > > Hi, > > > > > > > > I don't believe that the ERO is relevant here. The issue > > isn't that the > > > > messages get sent to the wrong next peer (which the ERO would > > > fix, albeit > > > > in a somewhat overweight way), it's that they are sent to the > > > right next > > > > peer, but with the wrong security association, because > > the source didn't > > > > know the next peer had changed. So this is essentially an > > > issue of how to > > > > discover and react to route changes. (At least I think so.) > > > > > > > > Cheers, > > > > > > > > Robert H. > > > > -----Original Message----- > > > > From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] > > > > Sent: 26 November 2002 17:55 > > > > To: nsis@ietf.org > > > > Subject: [NSIS] next peer issue in rsvp-sec > > > > > > > > > > > > > > > > Hi all, > > > > I think the Next Peer issue highlighted in the RSVP > > Security Properties > > > > slide > > > > > > (http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Proper > ties.ppt) > > > can be solved by adding an ERO (EXPLICIT_ROUTE object) in the > > > RSVP-PATH message. Of course the intervening network needs to > > > understand ERO. > > > > > > -Kuntal > > > > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C29662.225C7040 Content-Type: text/html RE: [NSIS] attempted summary of next-peer issue (was: RE: next peer issue in rsvp-sec)

Hi Robert,
I think point 3 is important to note. I don't see anything in the
w.g. charter that says "explicit route" capability is beyond
the scope of NSIS.

Section 4.1, assumption 5 and 6 in draft-ietf-nsis-req-05.txt has some
relevant texts on this subject:
"
5. We assume that there are means for the discovery of NSIS entities
   in order to know the signaling peers (solutions include static
   configuration, automatically discovered, or implicitly runs over the
   right nodes, etc.) The discovery of the NSIS entities has security
   implications that need to be addressed properly. These implications
   largely depend on the chosen protocol. For some security mechanisms
   (i.e. Kerberos, pre-shared secret) it is required to know the
   identity of the other entity. Hence the discovery mechanism may
   provide means to learn this identity, which is then later used to
   retrieve the required keys and parameters. 
   
   6. NSIS assumes to operate with networks using standard ("normal")
   L3 routing. Where "normal" is not specified more exactly on purpose.
"
I think assumption 5 is unclear as what "automatic discovery" really means.
However I think assumption 6 is (implicitly) in-line with your point 3.

Although not explicitly mentioned in the nsis-req draft, I guess the general
assumption in the w.g. is to only discuss issues with peers that are beyond
reach of IGP and nodes that can only do plain IP routing. In short, no "explicit
routing".

Thanks for the summary.

Regards,
Kuntal



> Hi Kuntal, Sven, Ping, Michael, John, Melinda, Hannes, all,
>
> It seems a number of issues have got combined here. Here is
> an attempted summary. Let me know if I missed or confused something.
>
> 1. If the originator knows the route the traffic is taking up
> to the next peer, it can send the signalling message to the
> right place no problem - there is *no next-peer issue* in
> this case. (This could be either because the originator is
> doing traffic engineering, or has complete IGP knowledge, or
> is telepathic, or whatever.) It can send the signalling
> message with an ERO object or with what the framework
> (currently) calls peer-peer addressing; in any case, there is
> *no problem*.
>
> 2. If you are in the fortunate position of knowing all nodes
> are NSIS-signalling capable, there is also *no next-peer
> issue* in this case. This is analogous to the IGP case. You
> know the signalling peer just by knowing the outgoing IP neighbour.
>
> 3. I believe we the NSIS w.g. are also (indeed, primarily???)
> interested in situations where (a) you are not traffic
> engineering or route pinning or assuming routing awareness,
> and (b) NTLP or indeed NSLP peers are far apart in IP terms.
> This is where the next-peer issue arises. And where, as
> Hannes points out, you also need to worry about the patherr
> messages in the other direction posing a security threat.
>
> [that's why you need security specialists - they always give
> the threat knife that one extra twist...]
>
> Is this accurate?
>
> Robert H.
>
>
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@siemens.com]
> > Sent: 27 November 2002 15:25
> > To: Ping Pan; sven.van_den_bosch@alcatel.be
> > Cc: Hancock, Robert; Kuntal Chowdhury; nsis@ietf.org
> > Subject: RE: [NSIS] next peer issue in rsvp-sec
> >
> >
> > hi ping
> >
> > referring to the security of rsvp-te and mpls in particular
> > is unfortunately
> > not very helpful. the way rsvp-te (and mpls) works is
> > different to rsvp (or
> > a generic signaling protocol) in general. hence you could
> > basically use
> > anything and it would work (in the worst case you can blame the
> > administrator for a bad network configuration). i would argue
> > that in case
> > of interdomain signaling everything is much easier compared
> > to end-to-end. i
> > bet that there are a few people who believe that you do not
> > need to secure
> > intra-domain signaling messages.
> >
> > i, however, think that there is a deployment problem for rsvp
> > since you
> > cannot assume that every router is an rsvp aware. (and we
> > want to skip the
> > policy issues, the missing key management and other things
> > for the moment).
> > hence i believe that the issues raised here are not only
> imagination.
> >
> > consider a case where rsvp signaling messages are interpreted
> > only at the
> > access networks and are treated transparently in the core
> > network (because
> > of overprovisioning, diffserv clouds, etc.). would you as an
> > access network
> > service provider be willing to make a qos reservation or some
> > processig
> > without having these signaling message to be properly secured?
> > sender-initiated messages and proxy operation would make the
> > situation more
> > difficult.
> >
> > i have two questions regarding igp:
> >
> > - how are messages delivered between two nodes? (transport
> > protocol/addressing)
> > - how does one node learn to which other node to send the message?
> > (discovery mechanism)
> >
> > ciao
> > hannes
> >
> >
> > > -----Original Message-----
> > > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On
> > Behalf Of Ping
> > > Pan
> > > Sent: Wednesday, November 27, 2002 9:45 AM
> > > To: sven.van_den_bosch@alcatel.be
> > > Cc: Hancock, Robert; Kuntal Chowdhury; nsis@ietf.org
> > > Subject: Re: [NSIS] next peer issue in rsvp-sec
> > >
> > >
> > > I thought ERO was invented for traffic engineering. Why is
> > it relevant
> > > to security?
> > >
> > > This entire RSVP security thread sounds fishy to me. RSVP is no
> > > different than IGP, where control messages are passed
> hop-by-hop. If
> > > people are happy with how routing protocols are handling
> with their
> > > security issues (MD5 and what not), then RSVP should just
> > adapt the same
> > > mechanism. I know some people are not happy with routing
> > security in the
> > > first place, then maybe this entire protocol security issue
> > should be
> > > considered else where.
> > >
> > > Finally, I am just curious about where this NSIS protocol
> would get
> > > deployed to have this security problem. In the backbone,
> > RSVP-TE seems
> > > to be fine as it is. I wonder if this is designed for
> mobile users.
> > >
> > > Thanks!
> > >
> > > - Ping
> > >
> > >
> > > sven.van_den_bosch@alcatel.be wrote:
> > > > Hi Robert, Kuntal, all,
> > > >
> > > > I interpreted the ERO comment as follows: The fact that
> > the security
> > > > association is now wrong results from the route change. The ERO
> > > is a way to
> > > > pin the route to what it originally was and thus prevents the
> > > route change.
> > > > This means that the security association will be the correct
> > > one. What do
> > > > you think?
> > > >
> > > > Cheers,
> > > > Sven.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > "Hancock, Robert" <robert.hancock@roke.co.uk>@ietf.org on
> > 27/11/2002
> > > > 00:50:26
> > > >
> > > > Sent by:  nsis-admin@ietf.org
> > > >
> > > >
> > > > To:   Kuntal Chowdhury <chowdury@nortelnetworks.com>,
> > nsis@ietf.org
> > > > cc:
> > > > Subject:  RE: [NSIS] next peer issue in rsvp-sec
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I  don't believe that the ERO is relevant here. The issue
> > isn't that the
> > > > messages  get sent to the wrong next peer (which the ERO would
> > > fix, albeit
> > > > in  a somewhat overweight way), it's that they are sent to the
> > > right next
> > > > peer, but with the wrong security association, because
> > the source didn't
> > > > know  the next peer had changed. So this is essentially an
> > > issue of how to
> > > > discover  and react to route changes. (At least I think so.)
> > > >
> > > > Cheers,
> > > >
> > > > Robert  H.
> > > > -----Original Message-----
> > > > From: Kuntal Chowdhury  [mailto:chowdury@nortelnetworks.com]
> > > > Sent: 26 November 2002  17:55
> > > > To: nsis@ietf.org
> > > > Subject: [NSIS] next peer issue in  rsvp-sec
> > > >
> > > >
> > > >
> > > > Hi all,
> > > > I think the Next Peer issue  highlighted in the RSVP
> > Security Properties
> > > > slide
> > > >
> > (http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Proper
> ties.ppt)
> > > can be solved by adding an ERO (EXPLICIT_ROUTE object)  in the
> > > RSVP-PATH message. Of course the intervening  network needs to
> > > understand ERO.
> > >
> > > -Kuntal
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > nsis mailing list
> > > nsis@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/nsis
> >
> >
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>

------_=_NextPart_001_01C29662.225C7040-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 17:22: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 RAA00107 for ; Wed, 27 Nov 2002 17:22:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARMPCl29822 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 17:25: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 gARMP8v29815; Wed, 27 Nov 2002 17:25: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 gARMOiv29790 for ; Wed, 27 Nov 2002 17:24:44 -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 RAA00100 for ; Wed, 27 Nov 2002 17:21:53 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gARMObK0004316; Wed, 27 Nov 2002 14:24:37 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABA48562; Wed, 27 Nov 2002 14:24:36 -0800 (PST) Message-Id: <200211272224.ABA48562@mira-sjc5-c.cisco.com> To: "Kuntal Chowdhury" cc: "Hancock, Robert" , nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] attempted summary of next-peer issue (was: RE: next pe er issue in rsvp-sec) In-Reply-To: Message from "Kuntal Chowdhury" of "Wed, 27 Nov 2002 16:12:54 CST." <23BDB0046F3ED51185CD0002A5608D24070BA1ED@zrc2c009.us.nortel.com> Date: Wed, 27 Nov 2002 17:24:36 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > I think assumption 5 is unclear as what "automatic discovery" really means. I think the document would benefit from the deletion of assumption 5. Somewhere, somehow, somebody needs to address the security issues around discovery, but I'm not sure that needs to be done in a requirement document unless there are actual requirements. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 18:19: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 SAA02100 for ; Wed, 27 Nov 2002 18:19:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARNMIU00777 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 18:22: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 gARNMEv00770; Wed, 27 Nov 2002 18:22: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 gARNLLv00717 for ; Wed, 27 Nov 2002 18:21:21 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02063 for ; Wed, 27 Nov 2002 18:18:30 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gARNLCB28408; Wed, 27 Nov 2002 15:21:12 -0800 (PST) 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 gARNLN320181; Wed, 27 Nov 2002 17:21:24 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Nov 2002 17:21:11 -0600 Message-ID: <23BDB0046F3ED51185CD0002A5608D24070BA231@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: Melinda Shore Cc: "Hancock, Robert" , nsis@ietf.org Subject: RE: [NSIS] attempted summary of next-peer issue (was: RE: next pe er issue in rsvp-sec) Date: Wed, 27 Nov 2002 17:21:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2966B.A9D6D110" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling 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_01C2966B.A9D6D110 Content-Type: text/plain Hi Melinda, So, according to you, NSIS-peer discovery should not be assumed in the requirements document. Is this correct? Also, this is an assumption. Do you suggest a similar requirement be added in the requirements section instead? -Kuntal > > > I think assumption 5 is unclear as what "automatic > discovery" really > > means. > > I think the document would benefit from the deletion of > assumption 5. Somewhere, somehow, somebody needs to address > the security issues around discovery, but I'm not sure that > needs to be done in a requirement document unless there are > actual requirements. > > Melinda > ------_=_NextPart_001_01C2966B.A9D6D110 Content-Type: text/html RE: [NSIS] attempted summary of next-peer issue (was: RE: next pe er issue in rsvp-sec)

Hi Melinda,
So, according to you, NSIS-peer discovery should not be assumed in
the requirements document. Is this correct?
Also, this is an assumption. Do you suggest a similar requirement
be added in the requirements section instead?

-Kuntal

>
> > I think assumption 5 is unclear as what "automatic
> discovery" really
> > means.
>
> I think the document would benefit from the deletion of
> assumption 5.  Somewhere, somehow, somebody needs to address
> the security issues around discovery, but I'm not sure that
> needs to be done in a requirement document unless there are
> actual requirements.
>
> Melinda
>

------_=_NextPart_001_01C2966B.A9D6D110-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Nov 27 18:38: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 SAA02747 for ; Wed, 27 Nov 2002 18:38:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gARNfE002256 for nsis-archive@odin.ietf.org; Wed, 27 Nov 2002 18:41: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 gARNfAv02218; Wed, 27 Nov 2002 18:41: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 gARNeAv02152 for ; Wed, 27 Nov 2002 18:40:10 -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 SAA02654 for ; Wed, 27 Nov 2002 18:37:18 -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 gARNdx0R013546; Wed, 27 Nov 2002 15:39:59 -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 ABA52336; Wed, 27 Nov 2002 15:40:01 -0800 (PST) Message-Id: <200211272340.ABA52336@mira-sjc5-c.cisco.com> To: "Kuntal Chowdhury" cc: "Hancock, Robert" , nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] attempted summary of next-peer issue (was: RE: next pe er issue in rsvp-sec) In-Reply-To: Message from "Kuntal Chowdhury" of "Wed, 27 Nov 2002 17:21:07 CST." <23BDB0046F3ED51185CD0002A5608D24070BA231@zrc2c009.us.nortel.com> Date: Wed, 27 Nov 2002 18:40:01 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > So, according to you, NSIS-peer discovery should not be assumed in > the requirements document. Is this correct? Not exactly. I think the text that's in there is very unclear and that we're better off deleting it and waiting until the framework is sufficiently well-developed so that we can correctly identify any requirements we have around discovery. Right now I think that different people have different discovery/routing models in mind, and it seems to me that we need to get those resolved before laying down any requirements. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 28 00:03:49 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 AAA09216 for ; Thu, 28 Nov 2002 00:03:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAS56C816921 for nsis-archive@odin.ietf.org; Thu, 28 Nov 2002 00:06: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 gAS54Yv16889; Thu, 28 Nov 2002 00:04: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 gAS53ev16868 for ; Thu, 28 Nov 2002 00:03:40 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09171 for ; Thu, 28 Nov 2002 00:00:45 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAS52q919709 for ; Thu, 28 Nov 2002 07:02:52 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Nov 2002 07:03:28 +0200 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 07:03:28 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Nov 2002 07:03:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Use IPSec draft Date: Thu, 28 Nov 2002 07:03:27 +0200 Message-ID: Thread-Topic: [NSIS] Use IPSec draft Thread-Index: AcKWVi69RwJwr48MSJ6nA/DnzLNfgQARSzxA To: , X-OriginalArrivalTime: 28 Nov 2002 05:03:28.0230 (UTC) FILETIME=[7D132860:01C2969B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAS53ev16869 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Robert, > I like this draft also, especially the warning in section 2 > ("If IPsec is a bad choice, use another standardized, > well-understood security protocol. Don't roll your own.") > Personally, I feel the security problems for general > path-coupled signalling taken as a whole are sufficiently > weird that it's worth considering how to slice the problem up > at the architectural stage to get a better match to existing > "standardized, well-understood security protocol[s]". But I > know other people object to this style of approach. I support this type of consideration. I think that security is just as important as scalability, so it should be a prime design consideration. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 28 08:43: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 IAA27832 for ; Thu, 28 Nov 2002 08:43:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gASDjTK21180 for nsis-archive@odin.ietf.org; Thu, 28 Nov 2002 08:45: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 gASDjLv21172; Thu, 28 Nov 2002 08:45: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 gASDgjv21121 for ; Thu, 28 Nov 2002 08:42:45 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27799 for ; Thu, 28 Nov 2002 08:39:56 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Nov 2002 13:42:41 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA6C6@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Date: Thu, 28 Nov 2002 13:42:40 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] Layer split issues Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Dear all, Following the NSIS session in Atlanta, I'd like to stimulate further discussion (and maybe agreement??) on some of the issues around where the NTLP/NSLP boundary should actually go. It seems to me there are 1) some options on which there is some agreement 2) some options on which there is some disagreement 3) some options we haven't really discussed yet or at least not properly. This email is an attempt to summarise (1) (i.e. find out whether I have read the mood right). Separate emails will cover some of the topics under (2). [I think (3) includes some real headaches (e.g. mobility handling/reservation identifiers, security attributes, coupled/decoupled aspects) which can reasonably be postponed before (1) and (2) are clearer.] Message Types ============= I think we can make a working assumption that the NTLP basically provides a capability like 'send data', without associating that data with creating a reservation, querying something, releasing resources, or whatever. The 'send data' message can go with or against the data flow, and only goes between NTLP peers. Is this valid? [There may be different variants of 'send data' depending on whether the NTLP can do state management stuff, I'm not prejudging that here.] [NB. There are potentially confusing comments within the framework about how much the NTLP and NSLP could be coupled/not properly independent layers. This is a historical overhang from when we used to think that the NTLP would have a richer message set. If the NTLP has only a very simple message set, these issues would go away.] Path Management =============== What was discussed/not objected in the framework session was (roughly) the assertion that the NTLP processing at each NSIS entity should include getting to the next NTLP peer, and that the NTLP should detect and maybe do something about path changes ("do something" may just be "tell the NSLP it's happened".) Left to its own devices, the NTLP would then implicitly construct the whole path (although I would content this shouldn't be described as giving the NTLP end to end capabilities). But the NSLP at any node is free to interfere however it wants anyway. I like this because it puts a large number of hard but signalling application independent, transport and lower layer issues inside the NTLP where they can be solved once. But I think there may be other views as well. Arguments? Sender/Receiver Issues ====================== The proposal (actually in an individual submission) is that, in so far as the NTLP has 'directionality': a) it only needs the functionality to get to the next NTLP peer in the sender-->receiver direction (might be called 'sender oriented') b) by default, it should be able to send its 'data' messages either direction, but as an optimisation, some signalling applications might only ask to send them sender-->receiver. However, we shouldn't make any restrictions on how (i.e. from which end) any NSLP should trigger the signalling process, request/authorise something, or whatever. In other words, NI and NR are NSLP concepts. I haven't heard counter-proposals, but the assumption is partly contingent on the path management assumption (so I'm asking). Is this a reasonable starting point? Cheers, Robert H. (Later, under (2), we get to state management and flow identification, where there are clearly interesting divergences of view.) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 28 09:02: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 JAA28044 for ; Thu, 28 Nov 2002 09:02:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gASE4ID21769 for nsis-archive@odin.ietf.org; Thu, 28 Nov 2002 09:04: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 gASE4Av21762; Thu, 28 Nov 2002 09:04: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 gASDk3v21228 for ; Thu, 28 Nov 2002 08:46:03 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27831 for ; Thu, 28 Nov 2002 08:43:11 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id gASDju621569; Thu, 28 Nov 2002 14:45:56 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id gASDjtC09796; Thu, 28 Nov 2002 14:45:55 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Kuntal Chowdhury" , "Hancock, Robert" , Subject: RE: [NSIS] attempted summary of next-peer issue (was: RE: next peer issue in rsvp-sec) Date: Thu, 28 Nov 2002 14:46:38 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0336_01C296EC.F5213E40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <23BDB0046F3ED51185CD0002A5608D24070BA1ED@zrc2c009.us.nortel.com> Importance: Normal Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0336_01C296EC.F5213E40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [NSIS] attempted summary of next-peer issue (was: RE: next peer issue in rsvp-sec)hi kuntal it is true that the charter says nothing like "explicit route capability is beyond the scope of NSIS". i guess that we can all agree that things typically used in traffic engineered networks are very special cases. hence it is fair to say that we cannot assume this behavior for all signaling applications/scenarios. can you agree with me? ciao hannes -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Kuntal Chowdhury Sent: Wednesday, November 27, 2002 11:13 PM To: Hancock, Robert; nsis@ietf.org Subject: RE: [NSIS] attempted summary of next-peer issue (was: RE: next peer issue in rsvp-sec) Hi Robert, I think point 3 is important to note. I don't see anything in the w.g. charter that says "explicit route" capability is beyond the scope of NSIS. Section 4.1, assumption 5 and 6 in draft-ietf-nsis-req-05.txt has some relevant texts on this subject: " 5. We assume that there are means for the discovery of NSIS entities in order to know the signaling peers (solutions include static configuration, automatically discovered, or implicitly runs over the right nodes, etc.) The discovery of the NSIS entities has security implications that need to be addressed properly. These implications largely depend on the chosen protocol. For some security mechanisms (i.e. Kerberos, pre-shared secret) it is required to know the identity of the other entity. Hence the discovery mechanism may provide means to learn this identity, which is then later used to retrieve the required keys and parameters. 6. NSIS assumes to operate with networks using standard ("normal") L3 routing. Where "normal" is not specified more exactly on purpose. " I think assumption 5 is unclear as what "automatic discovery" really means. However I think assumption 6 is (implicitly) in-line with your point 3. Although not explicitly mentioned in the nsis-req draft, I guess the general assumption in the w.g. is to only discuss issues with peers that are beyond reach of IGP and nodes that can only do plain IP routing. In short, no "explicit routing". Thanks for the summary. Regards, Kuntal > Hi Kuntal, Sven, Ping, Michael, John, Melinda, Hannes, all, > > It seems a number of issues have got combined here. Here is > an attempted summary. Let me know if I missed or confused something. > > 1. If the originator knows the route the traffic is taking up > to the next peer, it can send the signalling message to the > right place no problem - there is *no next-peer issue* in > this case. (This could be either because the originator is > doing traffic engineering, or has complete IGP knowledge, or > is telepathic, or whatever.) It can send the signalling > message with an ERO object or with what the framework > (currently) calls peer-peer addressing; in any case, there is > *no problem*. > > 2. If you are in the fortunate position of knowing all nodes > are NSIS-signalling capable, there is also *no next-peer > issue* in this case. This is analogous to the IGP case. You > know the signalling peer just by knowing the outgoing IP neighbour. > > 3. I believe we the NSIS w.g. are also (indeed, primarily???) > interested in situations where (a) you are not traffic > engineering or route pinning or assuming routing awareness, > and (b) NTLP or indeed NSLP peers are far apart in IP terms. > This is where the next-peer issue arises. And where, as > Hannes points out, you also need to worry about the patherr > messages in the other direction posing a security threat. > > [that's why you need security specialists - they always give > the threat knife that one extra twist...] > > Is this accurate? > > Robert H. > > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@siemens.com] > > Sent: 27 November 2002 15:25 > > To: Ping Pan; sven.van_den_bosch@alcatel.be > > Cc: Hancock, Robert; Kuntal Chowdhury; nsis@ietf.org > > Subject: RE: [NSIS] next peer issue in rsvp-sec > > > > > > hi ping > > > > referring to the security of rsvp-te and mpls in particular > > is unfortunately > > not very helpful. the way rsvp-te (and mpls) works is > > different to rsvp (or > > a generic signaling protocol) in general. hence you could > > basically use > > anything and it would work (in the worst case you can blame the > > administrator for a bad network configuration). i would argue > > that in case > > of interdomain signaling everything is much easier compared > > to end-to-end. i > > bet that there are a few people who believe that you do not > > need to secure > > intra-domain signaling messages. > > > > i, however, think that there is a deployment problem for rsvp > > since you > > cannot assume that every router is an rsvp aware. (and we > > want to skip the > > policy issues, the missing key management and other things > > for the moment). > > hence i believe that the issues raised here are not only > imagination. > > > > consider a case where rsvp signaling messages are interpreted > > only at the > > access networks and are treated transparently in the core > > network (because > > of overprovisioning, diffserv clouds, etc.). would you as an > > access network > > service provider be willing to make a qos reservation or some > > processig > > without having these signaling message to be properly secured? > > sender-initiated messages and proxy operation would make the > > situation more > > difficult. > > > > i have two questions regarding igp: > > > > - how are messages delivered between two nodes? (transport > > protocol/addressing) > > - how does one node learn to which other node to send the message? > > (discovery mechanism) > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On > > Behalf Of Ping > > > Pan > > > Sent: Wednesday, November 27, 2002 9:45 AM > > > To: sven.van_den_bosch@alcatel.be > > > Cc: Hancock, Robert; Kuntal Chowdhury; nsis@ietf.org > > > Subject: Re: [NSIS] next peer issue in rsvp-sec > > > > > > > > > I thought ERO was invented for traffic engineering. Why is > > it relevant > > > to security? > > > > > > This entire RSVP security thread sounds fishy to me. RSVP is no > > > different than IGP, where control messages are passed > hop-by-hop. If > > > people are happy with how routing protocols are handling > with their > > > security issues (MD5 and what not), then RSVP should just > > adapt the same > > > mechanism. I know some people are not happy with routing > > security in the > > > first place, then maybe this entire protocol security issue > > should be > > > considered else where. > > > > > > Finally, I am just curious about where this NSIS protocol > would get > > > deployed to have this security problem. In the backbone, > > RSVP-TE seems > > > to be fine as it is. I wonder if this is designed for > mobile users. > > > > > > Thanks! > > > > > > - Ping > > > > > > > > > sven.van_den_bosch@alcatel.be wrote: > > > > Hi Robert, Kuntal, all, > > > > > > > > I interpreted the ERO comment as follows: The fact that > > the security > > > > association is now wrong results from the route change. The ERO > > > is a way to > > > > pin the route to what it originally was and thus prevents the > > > route change. > > > > This means that the security association will be the correct > > > one. What do > > > > you think? > > > > > > > > Cheers, > > > > Sven. > > > > > > > > > > > > > > > > > > > > > > > > "Hancock, Robert" @ietf.org on > > 27/11/2002 > > > > 00:50:26 > > > > > > > > Sent by: nsis-admin@ietf.org > > > > > > > > > > > > To: Kuntal Chowdhury , > > nsis@ietf.org > > > > cc: > > > > Subject: RE: [NSIS] next peer issue in rsvp-sec > > > > > > > > > > > > > > > > Hi, > > > > > > > > I don't believe that the ERO is relevant here. The issue > > isn't that the > > > > messages get sent to the wrong next peer (which the ERO would > > > fix, albeit > > > > in a somewhat overweight way), it's that they are sent to the > > > right next > > > > peer, but with the wrong security association, because > > the source didn't > > > > know the next peer had changed. So this is essentially an > > > issue of how to > > > > discover and react to route changes. (At least I think so.) > > > > > > > > Cheers, > > > > > > > > Robert H. > > > > -----Original Message----- > > > > From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] > > > > Sent: 26 November 2002 17:55 > > > > To: nsis@ietf.org > > > > Subject: [NSIS] next peer issue in rsvp-sec > > > > > > > > > > > > > > > > Hi all, > > > > I think the Next Peer issue highlighted in the RSVP > > Security Properties > > > > slide > > > > > > (http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Proper > ties.ppt) > > > can be solved by adding an ERO (EXPLICIT_ROUTE object) in the > > > RSVP-PATH message. Of course the intervening network needs to > > > understand ERO. > > > > > > -Kuntal > > > > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------=_NextPart_000_0336_01C296EC.F5213E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] attempted summary of next-peer issue (was: = RE: next peer issue in rsvp-sec)
hi=20 kuntal=20
 
it is=20 true that the charter says nothing like "explicit route capability is beyond =
the scope of NSIS". i guess that we can all agree that things = typically=20 used in traffic engineered networks are very special cases. hence it is = fair to=20 say that we cannot assume this behavior for all signaling=20 applications/scenarios.
 
can=20 you agree with me?
 
ciao
hannes
 
-----Original Message-----
From: = nsis-admin@ietf.org=20 [mailto:nsis-admin@ietf.org]On Behalf Of Kuntal=20 Chowdhury
Sent: Wednesday, November 27, 2002 11:13 = PM
To:=20 Hancock, Robert; nsis@ietf.org
Subject: RE: [NSIS] attempted = summary=20 of next-peer issue (was: RE: next peer issue in = rsvp-sec)

Hi Robert,
I think point 3 = is=20 important to note. I don't see anything in the
w.g.=20 charter that says "explicit route" capability is beyond =
the scope of NSIS.

Section 4.1, assumption 5 and 6 in = draft-ietf-nsis-req-05.txt=20 has some
relevant texts on this = subject:=20
"
5. We assume that there = are means=20 for the discovery of NSIS entities
   in=20 order to know the signaling peers (solutions include static =
   configuration, automatically discovered, or = implicitly=20 runs over the
   right nodes, = etc.) The=20 discovery of the NSIS entities has security
   implications that need to be addressed properly. = These=20 implications
   largely depend on = the chosen=20 protocol. For some security mechanisms
  =20 (i.e. Kerberos, pre-shared secret) it is required to know the =
   identity of the other entity. Hence the = discovery=20 mechanism may
   provide means to = learn this=20 identity, which is then later used to
  =20 retrieve the required keys and parameters. 
   
   6. = NSIS assumes=20 to operate with networks using standard ("normal")
   L3 routing. Where "normal" is not specified more = exactly=20 on purpose.
"
I = think=20 assumption 5 is unclear as what "automatic discovery" really = means.=20
However I think assumption 6 is (implicitly) = in-line with=20 your point 3.

Although not explicitly mentioned in the nsis-req = draft, I=20 guess the general
assumption in the w.g. is = to only=20 discuss issues with peers that are beyond
reach of IGP=20 and nodes that can only do plain IP routing. In short, no = "explicit=20
routing".

Thanks for the summary.

Regards,
Kuntal =



> Hi Kuntal, Sven, Ping, Michael, John, Melinda, = Hannes,=20 all,
>
> It = seems a=20 number of issues have got combined here. Here is
>=20 an attempted summary. Let me know if I missed or confused = something.=20
>
> 1. If the = originator knows=20 the route the traffic is taking up
> to = the next=20 peer, it can send the signalling message to the
>=20 right place no problem - there is *no next-peer issue* in =
> this case. (This could be either because the originator = is=20
> doing traffic engineering, or has = complete IGP=20 knowledge, or
> is telepathic, or = whatever.) It can=20 send the signalling
> message with an ERO = object or=20 with what the framework
> (currently) = calls=20 peer-peer addressing; in any case, there is
> *no=20 problem*.
>
> 2. If you=20 are in the fortunate position of knowing all nodes
> are NSIS-signalling capable, there is also *no next-peer =
> issue* in this case. This is analogous = to the IGP=20 case. You
> know the signalling peer just = by=20 knowing the outgoing IP neighbour.
>=20
> 3. I believe we the NSIS w.g. are also = (indeed,=20 primarily???)
> interested in situations = where (a)=20 you are not traffic
> engineering or = route pinning=20 or assuming routing awareness,
> and (b) = NTLP or=20 indeed NSLP peers are far apart in IP terms.
> This=20 is where the next-peer issue arises. And where, as
> Hannes points out, you also need to worry about the = patherr=20
> messages in the other direction posing = a security=20 threat.
>
> = [that's why=20 you need security specialists - they always give
>=20 the threat knife that one extra twist...]
>=20
> Is this accurate?
>=20
> Robert H.
>=20
>
> > = -----Original=20 Message-----
> > From: Hannes = Tschofenig [mailto:Hannes.Tschofenig@si= emens.com]=20
> > Sent: 27 November 2002 15:25 =
> > To: Ping Pan; sven.van_den_bosch@alcatel.be =
> > Cc: Hancock, Robert; Kuntal Chowdhury; = nsis@ietf.org=20
> > Subject: RE: [NSIS] next peer issue in=20 rsvp-sec
> >
> >=20
> > hi ping
> >=20
> > referring to the security of = rsvp-te and=20 mpls in particular
> > is = unfortunately=20
> > not very helpful. the way rsvp-te (and = mpls) works=20 is
> > different to rsvp (or =
> > a generic signaling protocol) in general. hence you = could=20
> > basically use
>=20 > anything and it would work (in the worst case you can blame = the=20
> > administrator for a bad network = configuration). i=20 would argue
> > that in case =
> > of interdomain signaling everything is much easier = compared=20
> > to end-to-end. i
> > bet that there are a few people who believe that = you do not=20
> > need to secure
>=20 > intra-domain signaling messages.
> = >=20
> > i, however, think that there is a = deployment=20 problem for rsvp
> > since you =
> > cannot assume that every router is an rsvp aware. = (and we=20
> > want to skip the
> > policy issues, the missing key management and other = things=20
> > for the moment).
> > hence i believe that the issues raised here are not = only=20
> imagination.
> >=20
> > consider a case where rsvp = signaling=20 messages are interpreted
> > only at = the=20
> > access networks and are treated = transparently in=20 the core
> > network (because =
> > of overprovisioning, diffserv clouds, etc.). would = you as an=20
> > access network
>=20 > service provider be willing to make a qos reservation or some=20
> > processig
> >=20 without having these signaling message to be properly secured?=20
> > sender-initiated messages and proxy = operation would=20 make the
> > situation more =
> > difficult.
> > =
> > i have two questions regarding igp: =
> >
> > - how are = messages=20 delivered between two nodes? (transport
> = >=20 protocol/addressing)
> > - how does = one node=20 learn to which other node to send the message?
>=20 > (discovery mechanism)
> > =
> > ciao
> > = hannes=20
> >
> > =
> > > -----Original Message-----
>=20 > > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On=20
> > Behalf Of Ping
> >=20 > Pan
> > > Sent: Wednesday, = November 27,=20 2002 9:45 AM
> > > To:=20 sven.van_den_bosch@alcatel.be
> > > = Cc:=20 Hancock, Robert; Kuntal Chowdhury; nsis@ietf.org
>=20 > > Subject: Re: [NSIS] next peer issue in rsvp-sec =
> > >
> > = >
> > > I thought ERO was invented for traffic = engineering. Why=20 is
> > it relevant
>=20 > > to security?
> > > =
> > > This entire RSVP security thread sounds fishy = to me.=20 RSVP is no
> > > different than = IGP, where=20 control messages are passed
> hop-by-hop. = If=20
> > > people are happy with how = routing=20 protocols are handling
> with their=20
> > > security issues (MD5 and what = not),=20 then RSVP should just
> > adapt the = same=20
> > > mechanism. I know some people are = not happy=20 with routing
> > security in = the=20
> > > first place, then maybe this entire = protocol=20 security issue
> > should be =
> > > considered else where.
> >=20 >
> > > Finally, I am just = curious about=20 where this NSIS protocol
> would get=20
> > > deployed to have this = security problem.=20 In the backbone,
> > RSVP-TE = seems=20
> > > to be fine as it is. I wonder if = this is=20 designed for
> mobile users. =
> > >
> > > = Thanks!=20
> > >
> > = > -=20 Ping
> > >
> >=20 >
> > > = sven.van_den_bosch@alcatel.be=20 wrote:
> > > > Hi Robert, = Kuntal,=20 all,
> > > >
>=20 > > > I interpreted the ERO comment as follows: The fact = that=20
> > the security
> > >=20 > association is now wrong results from the route change. The = ERO=20
> > > is a way to
> >=20 > > pin the route to what it originally was and thus prevents = the=20
> > > route change.
>=20 > > > This means that the security association will be the=20 correct
> > > one. What do =
> > > > you think?
> = > >=20 >
> > > > Cheers, =
> > > > Sven.
> > = >=20 >
> > > >
>=20 > > >
> > > > =
> > > >
> > > = >=20 "Hancock, Robert" <robert.hancock@roke.co.uk>@ietf.org on =
> > 27/11/2002
> = > >=20 > 00:50:26
> > > > =
> > > > Sent by:  nsis-admin@ietf.org =
> > > >
> > > = >=20
> > > > To:   Kuntal = Chowdhury=20 <chowdury@nortelnetworks.com>,
> = >=20 nsis@ietf.org
> > > > cc: =
> > > > Subject:  RE: [NSIS] next peer issue = in=20 rsvp-sec
> > > > =
> > > >
> > > = >=20
> > > > Hi,
> >=20 > >
> > > > I  don't = believe=20 that the ERO is relevant here. The issue
> >=20 isn't that the
> > > > = messages  get=20 sent to the wrong next peer (which the ERO would
>=20 > > fix, albeit
> > > > = in  a=20 somewhat overweight way), it's that they are sent to the =
> > > right next
> > = > >=20 peer, but with the wrong security association, because =
> > the source didn't
> = > > >=20 know  the next peer had changed. So this is essentially an =
> > > issue of how to
>=20 > > > discover  and react to route changes. (At least I = think=20 so.)
> > > >
>=20 > > > Cheers,
> > > = >=20
> > > > Robert  H. =
> > > > -----Original Message----- =
> > > > From: Kuntal Chowdhury  [mailto:chowdury@nortelnetwork= s.com]=20
> > > > Sent: 26 November 2002  = 17:55=20
> > > > To: nsis@ietf.org =
> > > > Subject: [NSIS] next peer issue in =20 rsvp-sec
> > > > =
> > > >
> > > = >=20
> > > > Hi all,
> >=20 > > I think the Next Peer issue  highlighted in the = RSVP=20
> > Security Properties
>=20 > > > slide
> > > >=20
> > (http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Pr= oper=20
> ties.ppt)
> > = > can be=20 solved by adding an ERO (EXPLICIT_ROUTE object)  in the =
> > > RSVP-PATH message. Of course the = intervening =20 network needs to
> > > understand = ERO.=20
> > >
> > = >=20 -Kuntal
> > >
>=20 > >
> > >
>=20 > >
> > >=20 _______________________________________________
>=20 > > nsis mailing list
> > >=20 nsis@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/nsis =
> >
> > =
> > = _______________________________________________=20
> > nsis mailing list
> >=20 nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis =
>
>=20 _______________________________________________
>=20 nsis mailing list
> nsis@ietf.org =
> https://www1.ietf.org/mailman/listinfo/nsis =
> _______________________________________________ =
> nsis mailing list
>=20 nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis =
>

------=_NextPart_000_0336_01C296EC.F5213E40-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Nov 28 09:18: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 JAA28278 for ; Thu, 28 Nov 2002 09:18:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gASELDr22837 for nsis-archive@odin.ietf.org; Thu, 28 Nov 2002 09:21: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 gASEL7v22829; Thu, 28 Nov 2002 09:21: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 gASEKiv22814 for ; Thu, 28 Nov 2002 09:20:44 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28272 for ; Thu, 28 Nov 2002 09:17:56 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id gASEKdj25739; Thu, 28 Nov 2002 15:20:39 +0100 (MET) Received: from vk (sn52sun1.mchp.siemens.de [139.23.202.144]) by mail2.siemens.de (8.11.6/8.11.6) with SMTP id gASEKcC18373; Thu, 28 Nov 2002 15:20:38 +0100 (MET) Reply-To: From: "Hannes Tschofenig" To: "Kuntal Chowdhury" , "Hancock, Robert" , Subject: RE: [NSIS] attempted summary of next-peer issue (was: RE: next peer issue in rsvp-sec) Date: Thu, 28 Nov 2002 15:21:22 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi kuntal it is true that the charter says nothing like "explicit route capability is beyond the scope of NSIS". i guess that we can all agree that things typically used in traffic engineered networks are very special cases. hence it is fair to say that we cannot assume this behavior for all signaling applications/scenarios. can you agree with me? ciao hannes -----Original Message----- From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Kuntal Chowdhury Sent: Wednesday, November 27, 2002 11:13 PM To: Hancock, Robert; nsis@ietf.org Subject: RE: [NSIS] attempted summary of next-peer issue (was: RE: next peer issue in rsvp-sec) Hi Robert, I think point 3 is important to note. I don't see anything in the w.g. charter that says "explicit route" capability is beyond the scope of NSIS. Section 4.1, assumption 5 and 6 in draft-ietf-nsis-req-05.txt has some relevant texts on this subject: " 5. We assume that there are means for the discovery of NSIS entities in order to know the signaling peers (solutions include static configuration, automatically discovered, or implicitly runs over the right nodes, etc.) The discovery of the NSIS entities has security implications that need to be addressed properly. These implications largely depend on the chosen protocol. For some security mechanisms (i.e. Kerberos, pre-shared secret) it is required to know the identity of the other entity. Hence the discovery mechanism may provide means to learn this identity, which is then later used to retrieve the required keys and parameters. 6. NSIS assumes to operate with networks using standard ("normal") L3 routing. Where "normal" is not specified more exactly on purpose. " I think assumption 5 is unclear as what "automatic discovery" really means. However I think assumption 6 is (implicitly) in-line with your point 3. Although not explicitly mentioned in the nsis-req draft, I guess the general assumption in the w.g. is to only discuss issues with peers that are beyond reach of IGP and nodes that can only do plain IP routing. In short, no "explicit routing". Thanks for the summary. Regards, Kuntal _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis