The MPLS WG Archive

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

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
>