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

[Magnus Westerlund <[e-mail]>]

Francois Le Faucheur IMAP skrev:
> 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.

I don't think you need to import the text. However it might be worth 
moving the reference earlier in the section and clarify that many 
important issues are present in that document.

> 
> 
>> 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?
> 

I have forward the answer to the commenter and is hoping for some 
answers. However I do think you could try to say a bit about these 
issues. With or without the help or feedback from the commenter.

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

Can you please write up some text for the security consideration that 
clarifies when there will be issues in keying RSVP to protect against 
the possible attacks.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------