[Tsvwg] Re: IETF LC comments on draft-ietf-tsvwg-rsvp-ipsec

[Francois Le Faucheur IMAP <[e-mail]>]

Magnus and all,

As a follow up from our discussion in San Diego, here is a proposal/ 
request-for-guidance to address the comments below:

On 13 Oct 2006, at 11:55, Magnus Westerlund wrote:

> Hi, the IESG received the below comment during the ongoing IETF LC.  
> I would appreciate some response to it.
>
> "I think that the "Security Considerations" section of this
> document is significantly thin.  There are significant security risks
> associated with this sort of aggregation that I don't see discussed
> in much detail.

"RSVP Aggregation over Generic Aggregate RSVP reservations" as per  
this document is of course very very similar to "RSVP Aggregation  
over Aggregate RSVP reservation" as per RFC3175. The issues  
associated with "this sort of aggregation" were discussed in RFC3175,  
so we elected to refer to the security considerations in RFC3175. The  
current text says:
"
When generic aggregate reservations are used for aggregation of E2E
reservations, the security considerations discussed in [RSVP-AGG]
apply.
"
We could either keep it this way or replicate the relevant text. I  
would personally prefer keeping it that way because some of the  
security discussions relates to aggregation mechanisms (such as RSVP- 
E2E-IGNORE) which are specified in details in RFC3175 and only  
brought into our document by reference to RFC3175.
But I can bring in the relevant text if you recommend we do so.


> There should also be at least some mention of traffic
> analysis issues and the potential DDOS attacks on the network
> operator arising from this usage.

Regarding traffic analysis, I am not quite sure what is there to say.
It seems that if an entity uses RSVP to signal its reservation  
requirement from point A to point B, someone snooping RSVP signaling  
would be able to know ... what are the reservation requirement from  
point A to point B. That seems like a fundamental aspect of signaling.
Or is the point that using aggregation makes traffic analysis easier  
because you get the full aggregate requirement by snooping one message?
Is this worth mentioning this?
Is there something smarter/more useful that should be said about  
traffic analysis that is specific to this document?

>
> Unlike RIPv2 Authentication, RSVP Authentication has never had
> any measurably large deployment, as near as I can tell.

Actually, I believe there is significant use of RSVP Authentication  
in MPLS Traffic Engineering deployments.

> A practical
> to deploy key management strategy is not apparent to me right now
> for RSVP Authentication.  RSVP Auth keys need to be placed in all
> of the devices along a dynamic and *changing* flow path, so it is
> much harder to pre-position manual keys along the whole path.
> By contrast, OSPF and RIP have a well-defined and static set of
> legitimate participating routers, so one can pre-position manual keys
> in all of those OSPF/RIP routers (and that has been commonly done
> in numerous enterprise networks using OSPFv2 Auth or RIPv2 Auth).

Well, in environments where RSVP is deployed on all routers of a  
convex cloud, using pre-positioned keys for RSVP seems very similar  
to using pre-positioned keys for OSPF/RIP. I think pre-positioning  
keys with RSVP only gets more tricky in environments where you have  
non-RSVP routers in between RSVP routers.

But in any case, most of this discussion about general applicability  
of RSVP Authentication seems beyond the scope of this particular  
document. The one point I can see which is specific to this document,  
is that the aggregation mechanisms used here rely on the Aggregator  
to send an E2E Path message into the Aggregation region without  
knowing ahead of time which Deaggregator will be used. This aspect is  
already discussed in the document, which also mentions that one  
possible solution then is to use the same key across all Aggregators/ 
Deaggregators.

BTW, Pratik Bose, Fred Baker and I, plan to submit a document  
proposing a method for IPsec protection of RSVP which could be used  
in many RSVP environments, including the ones of generic aggregate  
RSVP. This may offer an alternative approach to the security concern  
discussed in previous paragraph. But this is future work, and need  
not be referenced from that document.


>
> If this gets published without addressing the above issues,
> I think EXPERIMENTAL would be more appropriate than STANDARDS-TRACK.
> That would let the community of interest have a stable spec
> to reference, as they sort through the poortly addressed issues
> that are outlined above."

We certainly wish to publish this document as STANDARDS-TRACK.  
Hopefully we can do so once we've agreed on resolution of these  
comments.

Thanks

Francois



>
>
> Best Regards
>
> Magnus Westerlund
>
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone [phone]
> Torshamsgatan 23           | Fax   [phone]
> S-164 80 Stockholm, Sweden | mailto: [e-mail]