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

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 16 Nov 2006 16:23:10 +0100

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 +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 17 Nov 2006 13:45:48 +0100

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:
> 
>> Hi, the IESG received the below comment during the ongoing IETF LC. I 
>> would appreciate some response to it.
>>
> "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:
> "
> 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.

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.

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

> Actually, I believe there is significant use of RSVP Authentication in 
> MPLS Traffic Engineering deployments.
> 
>> A practical
> 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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 17 Nov 2006 16:20:54 +0100

Hi,

Below is answers from Ran to Francois comments. You will need to keep 
him on the CC to discuss these issues.

---- Text from Ran Atkinson ----------------

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

The relevant text ought to be replicated, possibly editing it to
reflect whatever differences might exist between this and RFC-3175
and whatever we know/realise now that might not have been clearly
documented or understood then.

It is a fundamental aspect of *clear-text* *in-band* signalling.

It is not a fundamental aspect of in-band signalling.  For example,
one could provide confidentiality to the signalling traffic
(if one could figure out how to distribute keys properly).

It is not a fundamental aspect of signalling.  For example,
Signalling System 7 (used in the telephony world) is out-of-band,
so snooping by ordinary users generally isn't practical.

 > Is this worth mentioning this?

This is also worth mentioning, and it is a difference in risk
from ordinary RSVP usage.

I know of several ISPs that use RSVP for MPLS Traffic Engineering.
I do not know of *one* that has enabled RSVP Authentication for MPLS.
Several have said that RSVP Authentication is impractical to enable
because of the absence of suitable key management.  This has come
up in hallway conversations with operators at RIPE and NANOG in the
past.  More recently, I've heard complaints about this aspect of
RSVP informally from certain parts of the US Government.

This issue is not unique to RSVP.  For example, BGP Authentication
(or RIPv2 Authentication) faces similar challenges where we have a
suitable authentication mechanism, but the absence of suitable key
management is one of several reasons that BGP Authentication has
somewhat limited deployment.  If one looks at the RIPv2 Authentication
document (either the original one or the latest one), then one will
see that this key management issue for RIP is carefully described --
along with suggestions for how the IETF might be able to fill that gap
in future.

If the authors think that suitable key management exists for RSVP
in this usage, it would be VERY helpful to document that in the
SECURITY CONSIDERATIONS for this draft, so that operators who choose
to deploy this mechanism know how to do it.

Alternately, and more likely in my view, they should at least clearly
document this key management issue/gap with RSVP for this usage
in the SECURITY CONSIDERATIONS section.  If they think a reasonable
algorithm exists, by all means add a citation to REFERENCES and
mention that in SECURITY CONSIDERATIONS as a possible future approach.

In the case of RIPv2, RIP packets are typically sent via IP multicast
to a special IP multicast group.  So if/when IETF has a key management
protocol for multicast applications (there is, I believe, the MSEC WG
on this -- and both RFC-2094 and RFC-2095 give reasonable hope that
it is a tractable problem), then RIP can use that approach.  OSPF's
situation is essentially the same as RIP, since both use IP multicasting
to reserved multicast groups.

In the case of RSVP, packets are sent along a path, but the actual
path members are dynamic.  It is unclear to me that a key management
strategy even exists for this sort of deployment.  Maybe, and one
would have to give it a lot more thought, one could use a public-key
scheme along with a PKI (holding an incoming RSVP packet for the
relatively long time a key management protocol transaction would take
likely has adverse consequences for the flow being signalled).  If the
authors think such a strategy really exists, it would be helpful
to mention it and perhaps add a citation or two in the REFERENCES
section.

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

See above.  This analysis is flawed in that both RIP and OSPF use
special-purpose IP multicast groups, so they can use MSEC's multicast
key management.  RSVP does not use multicast, so it is not obvious
that it can use multicast key management.

 > But in any case, most of this discussion about general applicability 
of RSVP Authentication seems beyond the scope of this particular document.

Not at all.  If we have an issue with a security mechanism and some
protocol extension relies on that security mechanism, then the issue
remains unresolved for the usage in the extension document and
also should be clearly documented in the extension document's
SECURITY CONSIDERATIONS.

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

Since we don't have a way to actually manage keys, it isn't clear
that this is any more practical than the general case, though it is
good that it is already mentioned.

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

At least the existence of the current real-world issues that make
it hard for a deployment to be secured should be fully documented
in the SECURITY CONSIDERATIONS.  It might, depending on the IESG's views,
be reasonable to add a paragraph to SECURITY CONSIDERATIONS outlining
the general concept that the 3 folks names above have in mind for
key management and indicate that this is one possible future direction.

As Steve Bellovin would be very quick to point out, "just use IPsec"
is not always a very credible answer.  I am the original author of
AH and ESP; I co-chaired the IPsec WG for a while.  In this case,
the issue is not so much how to use AH/ESP with RSVP, which might be
what is meant by the quoted text above, but how would one manage the
keys.  It is not at all clear that a hybrid Diffie-Hellman scheme,
such as ISAKMP/IKE, can be used in an RSVP deployment such as is
described here.  This is UNLIKE the case with RIP or OSPF, which
use multicast for their messages, where there are published techniques
for multicast key management (RFC-2093, RFC-2094, and a wider number
in the open cryptographic literature) and there has been an IETF MSEC
WG actually developing multicast key management for IETF use.

It seems that if one looks through the above, at a bare minimum
significant new text (on several different topics) is needed in
this document's SECURITY CONSIDERATIONS section.

Yours,

Ran
[email-masked]

-- 

Magnus Westerlund