Re: help

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