The MPLS WG Archive

[Tschofenig Hannes <Hannes.Tschofenig@mchp.siemens.de>]

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
>