Subject: RE: [Rsvp] Re: help

From: Tschofenig Hannes <[email-masked]>
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
> [email-masked]
> http://mailman.isi.edu/mailman/listinfo/rsvp
> 
_______________________________________________
Rsvp mailing list
[email-masked]
http://mailman.isi.edu/mailman/listinfo/rsvp

---

From: David Charlap <[email-masked]>
Date: Tue, 04 Mar 2003 17:15:31 -0500

> your next rsvp aware router to select your security association to protect

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.

> know that your next node is rsvp capable and you might even know the entire

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