From 6bone-admin@mailman.isi.edu Sat Mar 1 08:17:25 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04334 for ; Sat, 1 Mar 2003 08:17:24 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h21DJOD01521 for ; Sat, 1 Mar 2003 05:19:24 -0800 (PST) Date: Sat, 1 Mar 2003 05:19:24 -0800 (PST) Message-Id: <200303011319.h21DJOD01521@gamma.isi.edu> Subject: mailman.isi.edu mailing list memberships reminder From: mailman-owner@mailman.isi.edu To: rsvp-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: 6bone-admin@mailman.isi.edu Errors-To: 6bone-admin@mailman.isi.edu X-BeenThere: 6bone@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk This is a reminder, sent out once a month, about your mailman.isi.edu mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, rsvp-request@mailman.isi.edu) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@mailman.isi.edu. Thanks! Passwords for rsvp-archive@lists.ietf.org: List Password // URL ---- -------- rsvp@mailman.isi.edu aspugu http://mailman.isi.edu/mailman/options/rsvp/rsvp-archive%40lists.ietf.org From rsvp-admin@mailman.isi.edu Sat Mar 1 20:58:14 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22286 for ; Sat, 1 Mar 2003 20:58:14 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h22206D00278; Sat, 1 Mar 2003 18:00:06 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h221xHD00205 for ; Sat, 1 Mar 2003 17:59:17 -0800 (PST) Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h221xHb28804 for ; Sat, 1 Mar 2003 17:59:17 -0800 (PST) Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h221xBS13041; Sat, 1 Mar 2003 17:59:11 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h221xAY43658; Sat, 1 Mar 2003 17:59:11 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs From: Kireeti Kompella To: ccamp@ops.ietf.org, "" , "" , "" , "" Message-ID: <20030301174430.O43585@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Rsvp] RSVP change document Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Sat, 1 Mar 2003 17:59:10 -0800 (PST) Hi All, The current venue for discussing draft-kompella-rsvp-change-00.txt (IANA Considerations and change process for RSVP) will be in the TSVWG (Thu 13:00-15:00 -- if not, I hope either the TSV ADs will correct me. For now, let's limit the discussion to the tsvwg mailing list. Kireeti. _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Tue Mar 4 11:58:35 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01189 for ; Tue, 4 Mar 2003 11:58:33 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h24H08Z28651; Tue, 4 Mar 2003 09:00:08 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h24Gw1Z27702 for ; Tue, 4 Mar 2003 08:58:01 -0800 (PST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h24Gw0F10259 for ; Tue, 4 Mar 2003 08:58:00 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03604; Tue, 4 Mar 2003 11:57:52 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27861; Tue, 4 Mar 2003 11:57:53 -0500 (EST) Message-ID: <3E64DB31.3020204@marconi.com> From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: mpls@UU.NET, rsvp@ISI.EDU References: <20030304053331.7670.qmail@webmail23.rediffmail.com> In-Reply-To: <20030304053331.7670.qmail@webmail23.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Rsvp] Re: help Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Tue, 04 Mar 2003 11:58:25 -0500 Content-Transfer-Encoding: 7bit Harish Kumtakar wrote: > > Why IPSEC can not be used in RSVP to care of security. Please throw > some light on this aspect. The reason it isn't in classical RSVP is because IPSEC secures two endpoints. But the nature of RSVP is such that packets are supposed to be intercepted and processed by transit routers. An RSVP router does not send a Path message to his neighbor. He sends it to the ultimate destination address, with the router-alert option, so that RSVP-aware routers along the way may intercept and process the packet. This is fundamentally incompatible with IPSEC - where the packet is encrypted such that transit routers can not intercept anything. If you want to use IPSEC with RSVP, then you must send packets directly to neighbors and abandon the use of router-alert. This isn't a problem for RSVP-TE, since the presence of non-RSVP routers isn't permitted in an MPLS/RSVP-TE network. But it eliminates the ability for classical RSVP to work over networks with non-RSVP nodes - something that is a key goal of the RSVP protocol. IPSEC also makes multicast much more CPU intensive. If every packet is encrypted, then you can't simply generate one Path message for transmission to all downstream nodes in a multicast group. You have to generate multiple separate packets and encrypt them individually. -- David _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Tue Mar 4 12:58:11 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03810 for ; Tue, 4 Mar 2003 12:58:10 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h24I06Z01488; Tue, 4 Mar 2003 10:00:06 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h24HxPZ01320 for ; Tue, 4 Mar 2003 09:59:26 -0800 (PST) Received: from fig.isi.edu (fig.isi.edu [128.9.160.78]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h24HxPF20138 for ; Tue, 4 Mar 2003 09:59:25 -0800 (PST) Received: from fig.isi.edu (localhost.localdomain [127.0.0.1]) by fig.isi.edu (8.12.8/8.12.8) with ESMTP id h24I0E1K014549; Tue, 4 Mar 2003 10:00:14 -0800 Received: from localhost (berson@localhost) by fig.isi.edu (8.12.8/8.12.5/Submit) with ESMTP id h24I0DFS014545; Tue, 4 Mar 2003 10:00:13 -0800 X-Authentication-Warning: fig.isi.edu: berson owned process doing -bs From: Steven Berson To: David Charlap cc: mpls@UU.NET, Subject: Re: [Rsvp] Re: help In-Reply-To: <3E64DB31.3020204@marconi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Tue, 4 Mar 2003 10:00:12 -0800 (PST) Actually, RSVP can be used with IPSEC. See RFC 2207, ``RSVP Extensions for IPSEC Data Flows''. Regards, Steve On Tue, 4 Mar 2003, David Charlap wrote: > Harish Kumtakar wrote: > > > > Why IPSEC can not be used in RSVP to care of security. Please throw > > some light on this aspect. > > The reason it isn't in classical RSVP is because IPSEC secures two > endpoints. But the nature of RSVP is such that packets are supposed to > be intercepted and processed by transit routers. > > An RSVP router does not send a Path message to his neighbor. He sends > it to the ultimate destination address, with the router-alert option, so > that RSVP-aware routers along the way may intercept and process the > packet. This is fundamentally incompatible with IPSEC - where the > packet is encrypted such that transit routers can not intercept anything. > > If you want to use IPSEC with RSVP, then you must send packets directly > to neighbors and abandon the use of router-alert. This isn't a problem > for RSVP-TE, since the presence of non-RSVP routers isn't permitted in > an MPLS/RSVP-TE network. But it eliminates the ability for classical > RSVP to work over networks with non-RSVP nodes - something that is a key > goal of the RSVP protocol. > > IPSEC also makes multicast much more CPU intensive. If every packet is > encrypted, then you can't simply generate one Path message for > transmission to all downstream nodes in a multicast group. You have to > generate multiple separate packets and encrypt them individually. > > -- David > > _______________________________________________ > Rsvp mailing list > Rsvp@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/rsvp > _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Tue Mar 4 13:38:10 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04858 for ; Tue, 4 Mar 2003 13:38:10 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h24Ie6Z22922; Tue, 4 Mar 2003 10:40:06 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h24IZjZ21775 for ; Tue, 4 Mar 2003 10:35:45 -0800 (PST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h24IZhF17643; Tue, 4 Mar 2003 10:35:43 -0800 (PST) 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 h24IZfb13869; Tue, 4 Mar 2003 19:35:41 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h24IZfr13590; Tue, 4 Mar 2003 19:35:41 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Mar 2003 19:35:40 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675EB4@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Steven Berson'" , David Charlap Cc: mpls@UU.NET, rsvp@ISI.EDU Subject: RE: [Rsvp] Re: help MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Tue, 4 Mar 2003 19:35:40 +0100 hi steve this is something different. rfc 2207 addresses ipsec protected data traffic. with this rfc the authors add the ability for rsvp to provide qos signaling for ipsec protected data traffic based on the available fields (spi instead of the port and transport protocol field). ciao hannes > -----Original Message----- > From: Steven Berson [mailto:berson@ISI.EDU] > Sent: Tuesday, March 04, 2003 7:00 PM > To: David Charlap > Cc: mpls@UU.NET; rsvp@ISI.EDU > Subject: Re: [Rsvp] Re: help > > > Actually, RSVP can be used with IPSEC. See RFC 2207, ``RSVP > Extensions for IPSEC Data Flows''. > > Regards, > Steve > > On Tue, 4 Mar 2003, David Charlap wrote: > > > Harish Kumtakar wrote: > > > > > > Why IPSEC can not be used in RSVP to care of > security. Please throw > > > some light on this aspect. > > > > The reason it isn't in classical RSVP is because IPSEC secures two > > endpoints. But the nature of RSVP is such that packets are > supposed to > > be intercepted and processed by transit routers. > > > > An RSVP router does not send a Path message to his > neighbor. He sends > > it to the ultimate destination address, with the > router-alert option, so > > that RSVP-aware routers along the way may intercept and process the > > packet. This is fundamentally incompatible with IPSEC - where the > > packet is encrypted such that transit routers can not > intercept anything. > > > > If you want to use IPSEC with RSVP, then you must send > packets directly > > to neighbors and abandon the use of router-alert. This > isn't a problem > > for RSVP-TE, since the presence of non-RSVP routers isn't > permitted in > > an MPLS/RSVP-TE network. But it eliminates the ability for > classical > > RSVP to work over networks with non-RSVP nodes - something > that is a key > > goal of the RSVP protocol. > > > > IPSEC also makes multicast much more CPU intensive. If > every packet is > > encrypted, then you can't simply generate one Path message for > > transmission to all downstream nodes in a multicast group. > You have to > > generate multiple separate packets and encrypt them individually. > > > > -- David > > > > _______________________________________________ > > Rsvp mailing list > > Rsvp@mailman.isi.edu > > http://mailman.isi.edu/mailman/listinfo/rsvp > > > > _______________________________________________ > Rsvp mailing list > Rsvp@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/rsvp > _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Tue Mar 4 13:40:56 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04925 for ; Tue, 4 Mar 2003 13:40:56 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h24IZAZ21202; Tue, 4 Mar 2003 10:35:10 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h24IWUZ20733 for ; Tue, 4 Mar 2003 10:32:30 -0800 (PST) Received: from fig.isi.edu (fig.isi.edu [128.9.160.78]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h24IWUF16288 for ; Tue, 4 Mar 2003 10:32:30 -0800 (PST) Received: from fig.isi.edu (localhost.localdomain [127.0.0.1]) by fig.isi.edu (8.12.8/8.12.8) with ESMTP id h24IXJ1K014697; Tue, 4 Mar 2003 10:33:19 -0800 Received: from localhost (berson@localhost) by fig.isi.edu (8.12.8/8.12.5/Submit) with ESMTP id h24IXJQ0014693; Tue, 4 Mar 2003 10:33:19 -0800 X-Authentication-Warning: fig.isi.edu: berson owned process doing -bs From: Steven Berson To: David Charlap cc: mpls@UU.NET, Subject: Re: [Rsvp] Re: help In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Tue, 4 Mar 2003 10:33:19 -0800 (PST) OK, I normally don't respond to my own messages, but I misunderstood the question. I understood the question to be asking how to use RSVP to reserve resources for IPSEC data flows. I don't recall seeing the original message, but as I read David's response carefully, it appears that the question really is about using IPSEC to protect the RSVP protocol messages themselves. David gives a good answer to the latter question. Regards, Steve On Tue, 4 Mar 2003, Steven Berson wrote: > Actually, RSVP can be used with IPSEC. See RFC 2207, ``RSVP > Extensions for IPSEC Data Flows''. > > Regards, > Steve > > On Tue, 4 Mar 2003, David Charlap wrote: > > > Harish Kumtakar wrote: > > > > > > Why IPSEC can not be used in RSVP to care of security. Please throw > > > some light on this aspect. > > > > The reason it isn't in classical RSVP is because IPSEC secures two > > endpoints. But the nature of RSVP is such that packets are supposed to > > be intercepted and processed by transit routers. > > > > An RSVP router does not send a Path message to his neighbor. He sends > > it to the ultimate destination address, with the router-alert option, so > > that RSVP-aware routers along the way may intercept and process the > > packet. This is fundamentally incompatible with IPSEC - where the > > packet is encrypted such that transit routers can not intercept anything. > > > > If you want to use IPSEC with RSVP, then you must send packets directly > > to neighbors and abandon the use of router-alert. This isn't a problem > > for RSVP-TE, since the presence of non-RSVP routers isn't permitted in > > an MPLS/RSVP-TE network. But it eliminates the ability for classical > > RSVP to work over networks with non-RSVP nodes - something that is a key > > goal of the RSVP protocol. > > > > IPSEC also makes multicast much more CPU intensive. If every packet is > > encrypted, then you can't simply generate one Path message for > > transmission to all downstream nodes in a multicast group. You have to > > generate multiple separate packets and encrypt them individually. > > > > -- David > > > > _______________________________________________ > > Rsvp mailing list > > Rsvp@mailman.isi.edu > > http://mailman.isi.edu/mailman/listinfo/rsvp > > > > _______________________________________________ > Rsvp mailing list > Rsvp@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/rsvp > _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Tue Mar 4 14:05:10 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05754 for ; Tue, 4 Mar 2003 14:05:09 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h24J56Z00381; Tue, 4 Mar 2003 11:05:06 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h24J0iZ29297 for ; Tue, 4 Mar 2003 11:00:44 -0800 (PST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h24J0hF00860 for ; Tue, 4 Mar 2003 11:00:43 -0800 (PST) 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 h24J0fb23200; Tue, 4 Mar 2003 20:00:41 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h24J0fr22763; Tue, 4 Mar 2003 20:00:41 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Mar 2003 20:00:40 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675EB5@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'David Charlap'" , mpls@UU.NET, rsvp@ISI.EDU Subject: RE: [Rsvp] Re: help MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Tue, 4 Mar 2003 20:00:40 +0100 hi all, thanks for raising this issue. please see my comments below: > Harish Kumtakar wrote: > > > > Why IPSEC can not be used in RSVP to care of security. > Please throw > > some light on this aspect. > > The reason it isn't in classical RSVP is because IPSEC secures two > endpoints. But the nature of RSVP is such that packets are > supposed to > be intercepted and processed by transit routers. > > An RSVP router does not send a Path message to his neighbor. > He sends > it to the ultimate destination address, with the router-alert > option, so > that RSVP-aware routers along the way may intercept and process the > packet. This is fundamentally incompatible with IPSEC - where the > packet is encrypted such that transit routers can not > intercept anything. may i summarize this issue: the problem is the combination of signaling message delivery and discovery. (there is a relationship to the end-to-end addressing.) using this combination is probably not the best idea since you have to know your next rsvp aware router to select your security association to protect it properly. > > If you want to use IPSEC with RSVP, then you must send > packets directly > to neighbors and abandon the use of router-alert. This isn't > a problem > for RSVP-TE, since the presence of non-RSVP routers isn't > permitted in > an MPLS/RSVP-TE network. i guess that there are more issues: the rsvp-te signaling message is still addressed to the destination address (rather than to the next rsvp node) although it might contain a route object. hence you use a discovery although you do not really need it (you know that your next node is rsvp capable and you might even know the entire path.) protecting a rsvp-te can only be done in ipsec tunnel mode. ipsec tunnel mode modifies the routing of the signaling message. to protect an rsvp signaling message (with ipsec) requires that you have have an spd entry which says which traffic is going to be protected. if you have more than one possible path (two possible neighboring routers) then you have two make your spd entry accordingly. which is difficult since the source address and the destination address is not the address of the nodes where the protected rsvp message should travel. if you manage it to create this ipsec sa then you need to change it once a route change happens to reflect the new path. But it eliminates the ability for classical > RSVP to work over networks with non-RSVP nodes - something > that is a key > goal of the RSVP protocol. for ipsec handling there are more difficulties. the fact that you do not necessarily know your next rsvp capable router is a bad thing (especially in case of non-rsvp cloudes/nodes or for applications such as middlebox communication where nodes are sparsely distributed. > > IPSEC also makes multicast much more CPU intensive. If every > packet is > encrypted, then you can't simply generate one Path message for > transmission to all downstream nodes in a multicast group. > You have to > generate multiple separate packets and encrypt them individually. my 5-cents on the multicast handling. since the path message is addressed to the destination ip address (which is a multicast address in this case) you have to use multicast security for message security. if you sparate signaling message delivery from discovery i guess that you could address individual rsvp nodes directly. btw, you might want to take a look at section 5 of http://www.tschofenig.com/drafts/draft-ietf-nsis-rsvp-sec-properties-01.txt. i would highly appreciate your comments. ciao hannes > > -- David > > _______________________________________________ > Rsvp mailing list > Rsvp@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/rsvp > _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Tue Mar 4 17:18:11 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12390 for ; Tue, 4 Mar 2003 17:18:10 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h24MK7Z28393; Tue, 4 Mar 2003 14:20:07 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h24MF5Z24087 for ; Tue, 4 Mar 2003 14:15:06 -0800 (PST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h24MF4F28404 for ; Tue, 4 Mar 2003 14:15:04 -0800 (PST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA17085; Tue, 4 Mar 2003 17:14:57 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA10005; Tue, 4 Mar 2003 17:14:58 -0500 (EST) Message-ID: <3E652583.8070402@marconi.com> From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en, he MIME-Version: 1.0 To: mpls@UU.NET, rsvp@ISI.EDU Subject: Re: [Rsvp] Re: help References: <2A8DB02E3018D411901B009027FD3A3F03675EB5@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03675EB5@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Tue, 04 Mar 2003 17:15:31 -0500 Content-Transfer-Encoding: 7bit Tschofenig Hannes wrote: > > may i summarize this issue: > the problem is the combination of signaling message delivery and discovery. > (there is a relationship to the end-to-end addressing.) > > using this combination is probably not the best idea since you have to know > your next rsvp aware router to select your security association to protect > it properly. Absolutely. In a classical-RSVP environment, you can't know your immediate next-RSVP-neighbor. Your route-table next hop may not be running RSVP - meaning he'll forward the packet and the first router to actually process it will be someone else. > the rsvp-te signaling message is still addressed to the destination address > (rather than to the next rsvp node) although it might contain a route > object. hence you use a discovery although you do not really need it (you > know that your next node is rsvp capable and you might even know the entire > path.) Under some circumstances (such as using the hierarchical LSP draft with unicast LSPs), it is legal to compute the next-hop address from the local route table and set the destination address to it. If this is done, IPSEC would be possible. RFC 2205 doesn't allow this sort of behavior for two main reasons. First, it breaks in the presence of non-RSVP routers along the path to the destination. Second, it creates the possibility that the Path message doesn't follow the same path as the data flow it represents. (Different addresses may result in different ECMP computation results.) RFC 3209 doesn't say anything for or against this behavior (although it does mandate that Hello messages be sent directly to the next-hop.) It may be reasonable to not assume that this requirement has been inherited from RFC 2205, because the arguments are not applicable. Concern for non-RSVP routers doesn't exist in RSVP-TE, and the data will always follow the Path message, using the LSP that it has established. In GMPLS, the reasons become even weaker, since part of GMPLS's capabilities involve explicitly signaling Path messages along a path separate from where the data will go. But even here, it is far from certain if this should be legal in the first place. The only draft I've read that actually requires Path messages to be sent directly to a next-hop is the hierarchical LSP draft. It is perfectly logical to assume that this is the only situation where it should be legal. Personally, I think the existing INTEGRITY object mechanism provides security that is good enough for RSVP signaling. Messages are authenticated, even if the data is not encrypted. But I'm not a security expert here - there may be a good reason why you'd want to prohibit a packet sniffer from looking at the content of RSVP control plane traffic. -- David _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Tue Mar 11 08:13:13 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18352 for ; Tue, 11 Mar 2003 08:13:13 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h2BDFBZ10456; Tue, 11 Mar 2003 05:15:11 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h245YlZ09900 for ; Mon, 3 Mar 2003 21:34:47 -0800 (PST) Received: from rediffmail.com (webmail23.rediffmail.com [203.199.83.145] (may be forged)) by tnt.isi.edu (8.11.6/8.11.2) with SMTP id h245YkF00483 for ; Mon, 3 Mar 2003 21:34:46 -0800 (PST) Received: (qmail 7671 invoked by uid 510); 4 Mar 2003 05:33:31 -0000 Message-ID: <20030304053331.7670.qmail@webmail23.rediffmail.com> Received: from unknown (203.200.20.226) by rediffmail.com via HTTP; 04 mar 2003 05:33:31 -0000 MIME-Version: 1.0 From: "Harish Kumtakar" Reply-To: "Harish Kumtakar" To: mpls@UU.NET, rsvp@ISI.EDU Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [Rsvp] help Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: 4 Mar 2003 05:33:31 -0000 hi, Why IPSEC can not be used in RSVP to care of security. Please throw some light on this aspect. Regards -harish Harish Kumtakar Samsung India Software Operations Samsung Digital House No. 67, Infantry Road Bangalore - 560 001 Ph: 5550555 extn:2260 _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Tue Mar 11 08:13:19 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18370 for ; Tue, 11 Mar 2003 08:13:18 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h2BDFGZ10495; Tue, 11 Mar 2003 05:15:17 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h24FQpZ28287 for ; Tue, 4 Mar 2003 07:26:51 -0800 (PST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h24FQoF27756 for ; Tue, 4 Mar 2003 07:26:50 -0800 (PST) Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h24FQia08384 for ; Tue, 4 Mar 2003 10:26:44 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id <1HW0HSGJ>; Tue, 4 Mar 2003 10:26:43 -0500 Message-ID: From: "Jiang, Donghua (Jane)" To: "'Harish Kumtakar'" , mpls@UU.NET, rsvp@ISI.EDU MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Rsvp] RE: help Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Tue, 4 Mar 2003 10:26:34 -0500 Harish, I don't think it is an issue of whether IPSec can or cannot be used in RSVP. It is an issue of what we want IPSec to do with RSVP. The concept of IPSec is to encode IP packets so no one can intercept the IP packets while the IP packets are in transit between two end points. If we encode RSVP packet with IPSec, do we expect RSVP nodes in between to understand the encoded RSVP packet? We could implement IPSec between two RSVP nodes, if we fear the link between the two RSVP nodes is not safe at all. Then, implementing IPSec hop by hop between RSVP nodes along the path might be too much. IPSec is generally meant to be applied in "end-to-end" situation rather than "hop-by-hop" situation. Regards, Jane D. Jiang -----Original Message----- From: Harish Kumtakar [mailto:harishk3@rediffmail.com] Sent: Tuesday, March 04, 2003 12:34 AM To: mpls@UU.NET; rsvp@isi.edu Subject: help hi, Why IPSEC can not be used in RSVP to care of security. Please throw some light on this aspect. Regards -harish Harish Kumtakar Samsung India Software Operations Samsung Digital House No. 67, Infantry Road Bangalore - 560 001 Ph: 5550555 extn:2260 _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Tue Mar 11 08:13:20 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18376 for ; Tue, 11 Mar 2003 08:13:19 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h2BDFMZ10578; Tue, 11 Mar 2003 05:15:22 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h24JY9Z12876 for ; Tue, 4 Mar 2003 11:34:09 -0800 (PST) Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h24JY8F23657; Tue, 4 Mar 2003 11:34:08 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h24JY0Nh016408; Tue, 4 Mar 2003 14:34:01 -0500 (EST) Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA24766; Tue, 4 Mar 2003 14:34:00 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA19202; Tue, 4 Mar 2003 14:34:00 -0500 (EST) Message-Id: <200303041934.OAA19202@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Steven Berson cc: David Charlap , mpls@UU.NET, rsvp@ISI.EDU, swallow@cisco.com Subject: Re: [Rsvp] Re: help In-reply-to: Your message of "Tue, 04 Mar 2003 10:00:12 PST." From: George Swallow Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Tue, 04 Mar 2003 14:34:00 -0500 Steven - I believe that 2207 deals with getting reservations for IPSEC flows. The subject of this thread is using IPSEC to secure RSVP protocol exchanges. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp From rsvp-admin@mailman.isi.edu Tue Mar 11 09:10:50 2003 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18369 for ; Tue, 11 Mar 2003 08:13:18 -0500 (EST) Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h2BDF6Z10397; Tue, 11 Mar 2003 05:15:06 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h22252D01465 for ; Sat, 1 Mar 2003 18:05:03 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h22252b02809 for ; Sat, 1 Mar 2003 18:05:02 -0800 (PST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.6/8.12.2) id h2224RSe010090; Sat, 1 Mar 2003 21:04:27 -0500 (EST) From: Scott Bradner Message-Id: <200303020204.h2224RSe010090@newdev.harvard.edu> To: ccamp@ops.ietf.org, kireeti@juniper.net, mpls@uu.net, nsis@ietf.org, rsvp@ISI.EDU, tsvwg@ietf.org Subject: Re: [Rsvp] RSVP change document Cc: Jon.peterson@neustar.com, mankin@psg.com In-Reply-To: <20030301174430.O43585@kummer.juniper.net> Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Sat, 1 Mar 2003 21:04:27 -0500 (EST) the tsvwg list will be the main venue I will talk with Allison to see if there is time in teh tsvwg meeting to start the dicussion Scott --- From rsvp-admin@mailman.isi.edu Sat Mar 1 21:00:42 2003 X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs From: Kireeti Kompella To: ccamp@ops.ietf.org, "" , "" , "" , "" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Rsvp] RSVP change document Sender: rsvp-admin@mailman.isi.edu Errors-To: rsvp-admin@mailman.isi.edu X-BeenThere: rsvp@mailman.isi.edu X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Archive: Date: Sat, 1 Mar 2003 17:59:10 -0800 (PST) Hi All, The current venue for discussing draft-kompella-rsvp-change-00.txt (IANA Considerations and change process for RSVP) will be in the TSVWG (Thu 13:00-15:00 -- if not, I hope either the TSV ADs will correct me. For now, let's limit the discussion to the tsvwg mailing list. Kireeti. _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp _______________________________________________ Rsvp mailing list Rsvp@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/rsvp