The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Mar> msg00071



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[Rsvp] Re: help

  • From: Steven Berson <berson@isi.edu>
  • Date: Tue, 4 Mar 2003 10:00:12 -0800 (PST)
  • cc: mpls@UU.NET, <rsvp@isi.edu>

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
> 


  • References:
    • help
      • From: David Charlap <David.Charlap@marconi.com>