[Rsvp] Re: help

[David Charlap]

Tschofenig Hannes wrote:
> 
> 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. 

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.

> 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.)

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