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

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 14 Dec 2006 10:28:51 +0100

All,

Below is a proposal for a considerably expanded Security Section for  
draft-ietf-tsvwg-rsvp-ipsec, based on our earlier discussions and  
input from Ran.
Please comment by X-mas as I'd like to post an updated version round  
then, and this is the only remaining open issue.

Thanks

Francois

====================================================================
Security Considerations

In the environments addressed by this document, RSVP messages are  
used to control resource reservations for generic aggregate  
reservations and may be used to control resource reservations for E2E  
reservations being aggregated over the generic aggregate  
reservations. To ensure the integrity of the associated reservation  
and admission control mechanisms, the RSVP Authentication mechanisms  
defined in [RSVP-CRYPTO1] and [RSVP-CRYPTO2] may be used. These  
protect RSVP message integrity hop-by-hop and provide node  
authentication as well as replay protection, thereby protecting  
against corruption and spoofing of RSVP messages. These hop-by-hop  
integrity mechanisms can be naturally used to protect the RSVP  
messages used for generic aggregate reservations and to protect RSVP  
messages used for E2E reservations outside the aggregation region.  
These hop-by-hop RSVP integrity mechanisms can also be used to  
protect RSVP messages used for E2E reservations when those transit  
through the aggregation region. This is because the Aggregator and  
Deaggregator behave as RSVP neighbors from the viewpoint of the E2E  
flows (even if they are not necessarily IP neighbors).

[RSVP-CRYPTO1] discusses several approaches for key distribution.  
First, the RSVP Authentication shared keys can be distributed  
manually. This is the base option and its support is mandated for any  
implementation. However, in some environments, this approach may  
become a burden if keys frequently change over time. Alternatively, a  
standard key management protocol for secure key distribution can be  
used. However, existing key distribution protocols may not be  
appropriate in all environments because of the complexity or  
operational burden they involve. Finally, [RSVP-CRYPTO1] specifies  
how Kerberos [KERBEROS] may be used to generate the RSVP  
Authentication keys. Kerberos allows for the use of trusted third  
party keying relationships between security principals (RSVP sender  
and receivers) where the Kerberos key distribution center (KDC)  
establishes an ephemeral session key to be shared between RSVP sender  
and receivers.

The use of RSVP Authentication in parts of the network where there  
may be one or more IP hops in between two RSVP neighbors raises an  
additional challenge. This is because, with some RSVP messages such  
as a Path message, an RSVP router does not know the RSVP next hop for  
that message at the time of forwarding it. In fact, part of the role  
of a Path message is precisely to discover the RSVP next hop (and to  
dynamically re-discover it when it changes, say because of a routing  
change). Hence, the RSVP router may not know which security  
association to use when forwarding such a message. This applies in  
particular to the case where RSVP Authentication mechanisms are to be  
used for protection of RSVP E2E messages (e.g. E2E Path) while they  
transit through an aggregation region and where the dynamic  
Deaggregator determination procedure defined in [RSVP-AGG] is used.  
This is because the Aggregator and the Deaggregator behave as RSVP  
neighbors for the E2E reservation, while there may be one or more IP  
hops in between them, and the Aggregator does not know ahead of time  
which router is going to act as the Deaggregator.

In that situation, one approach is to share the same RSVP  
Authentication shared key across all the RSVP routers of a part of  
the network where there may be RSVP neighbors with IP hops in  
between. For example, all the Aggregators or Deaggregators of an  
aggregation region could share the same RSVP Authentication key,  
while different per-neighbor keys could be used between any RSVP  
router pair straddling the boundary between two administrative  
domains that have agreed to use RSVP signaling.

When the same RSVP Authentication shared key is to be shared among  
multiple RSVP neighbors, manual key distribution may be used. In the  
future, automated key distribution techniques suitable for this  
situation may become available. Possible examples include the  
adaptation of multicast key management techniques such as those  
developed by the IETF MSEC Working Group or those commonly used for  
Multicast key distribution in WiFi environments, to this scenario  
wherein the same key also needs to be dynamically distributed to  
multiple routers of a particular community (i.e. the RSVP routers  
here). Specification of such automated key distribution techniques or  
of their applicability to RSVP is out of the scope of this document.

The RSVP Authentication mechanisms do not provide confidentiality. If  
confidentiality is required, IPsec ESP [IPSEC-ESP] may be used,  
although it imposes the burden of key distribution. It also faces the  
additional issue discussed for key management above in case there can  
be IP hops in between RSVP hops. In the future, confidentiality  
solutions may be developed for the case where there can be IP hops in  
between RSVP hops, perhaps by adapting confidentiality solutions  
developed by the IETF MSEC Working Group. Such confidentiality  
solutions for RSVP are outside the scope of this document.

Protection against traffic analysis is also not provided by RSVP  
Authentication. Since generic aggregate reservations are intended to  
reserve resources collectively for a whole set of users or hosts,  
malicious snooping of the corresponding RSVP messages could provide  
more traffic analysis information than snooping of an E2E  
reservation. When RSVP neighbors are directly attached, mechanisms  
such as bulk link encryption might be used when protection against  
traffic analysis is required. This approach could be used inside the  
aggregation region for protection of the generic aggregate  
reservations. It may also be used outside the aggregation region for  
protection of the E2E reservation. However, it is not applicable to  
the protection of E2E reservations while the corresponding E2E RSVP  
messages transit through the aggregation region.

When generic aggregate reservations are used for aggregation of E2E  
reservations, the security considerations discussed in [RSVP-AGG]  
apply and are revisited here.

First, the loss of an aggregate reservation to an aggressor causes  
E2E flows to operate unreserved, and the reservation of a great  
excess of bandwidth may result in a denial of service. These issues  
are not confined to the extensions defined in the present document:  
RSVP itself has them. However, they may be exacerbated here by the  
fact that each aggregate reservation typically facilitates  
communication for many sessions. Hence compromising one such  
aggregate reservation can result in more damage than compromising a  
typical E2E reservation. Use of the RSVP Authentication mechanisms to  
protect against such attacks has been discussed above.

An additional security consideration specific to RSVP aggregation  
involves the modification of the IP protocol number in RSVP Path  
messages that traverse an aggregation region. Malicious modification  
of the IP protocol number in a Path message would cause the message  
to be ignored by all subsequent RSVP devices on its path, preventing  
reservations from being made. It could even be possible to correct  
the value before it reached the receiver, making it difficult to  
detect the attack. Note that in theory, it might also be possible for  
a node to modify the IP protocol number for non-RSVP messages as  
well, thus interfering with the operation of other protocols. One way  
to mitigate the risks of malicious modification of the IP protocol  
number is to use an IPsec authentication header, which would ensure  
that malicious modification of the IP header is detected. This is a  
desirable approach but again imposes some administrative burden in  
the form of key management for authentication purposes and may again  
face the additional key management issue discussed above where there  
can be IP hops in between RSVP neighbors. It is RECOMMENDED that  
implementations of this specification only support modification of  
the IP protocol number for RSVP Path, PathTear, and ResvConf  
messages. That is, a general facility for modification of the IP  
protocol number SHOULD NOT be made available.

Network operators deploying routers with RSVP aggregation capability  
should be aware of the risks of inappropriate modification of the IP  
protocol number and should take appropriate steps (physical security,  
password protection, etc.) to reduce the risk that a router could be  
configured by an attacker to perform malicious modification of the  
protocol number.

===========================================================

On 17 Nov 2006, at 16:20, Magnus Westerlund wrote:

> 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 ----------------
>
> > 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.
>
> 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.
>
> >> 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.
>
> 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.
>
> > 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?
>
> This is also worth mentioning, and it is a difference in risk
> from ordinary RSVP usage.
>
> > 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.
>
> 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.
>
> >> 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.
>
> 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
>
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> 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: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 14 Dec 2006 17:35:59 +0100

Hi Ran,

Thanks for your prompt review. Please see embedded comments below:

On 14 Dec 2006, at 16:13, RJ Atkinson wrote:

>
> First, I'd like to thank Francois and the other authors for
> undertaking these improvements to the document's Security
> Considerations.  Writing good Security Considerations is not
> trivial

certainly not for me '^). And I appreciate the help here.

> and is important.
>
> On  14 Dec 2006, at 04:28, Francois Le Faucheur IMAP wrote:
>> reservations and may be used to control resource reservations for  
>> E2E reservations being aggregated over the generic aggregate  
>> reservations. To ensure the integrity of the associated  
>> reservation and admission control mechanisms, the RSVP  
>> Authentication mechanisms defined in [RSVP-CRYPTO1] and [RSVP- 
>> CRYPTO2] may be used. These protect RSVP message integrity hop-by- 
>> hop and provide node authentication as well as replay protection,  
>> thereby protecting against corruption and spoofing of RSVP  
>> messages. These hop-by-hop integrity mechanisms can be naturally  
>> used to protect the RSVP messages used for generic aggregate  
>> reservations and to protect RSVP messages used for E2E  
>> reservations outside the aggregation region. These hop-by-hop RSVP  
>> integrity mechanisms can also be used to protect RSVP messages  
>> used for E2E reservations when those transit through the  
>> aggregation region. This is because the Aggregator and  
>> Deaggregator behave as RSVP neighbors from the viewpoint of the  
>> E2E flows (even if they are not necessarily IP neighbors).
>>
>> manually. This is the base option and its support is mandated for  
>> any implementation. However, in some environments, this approach  
>> may become a burden if keys frequently change over time.
>
> As Sam Hartman has mentioned to me more than once, the IETF's
> operational experience is that security mechanisms that rely
> upon manual key distribution generally do not get wide deployment
> and so are significantly less effective operationally than
> mechanisms that have some form of (secure) automated key management
> mechanism defined and available.
>
> Whether or not keys change over time, one would have to know
> a priori which routers to manually configure with which keys.
> This seems operationally burdensome -- at least based on my own
> prior experience in network engineering/operations in either
> enterprise networks or service provider networks.

So I take it that you're in violent agreement with the proposed text  
capturing the gist of this concern ("this approach may become a  
burden if keys frequently change over time"). right?

>
>> Alternatively, a standard key management protocol for secure key  
>> distribution can be used.
>> However, existing key distribution protocols may not be  
>> party keying relationships between security principals (RSVP  
>> sender and receivers) where the Kerberos key distribution center  
>> (KDC) establishes an ephemeral session key to be shared between  
>> RSVP sender and receivers.
>
> I'm very glad to see this discussion and the references.  Kerberos
> can sometimes be a good key distribution mechanism for routers.
> At least one large service provider has a Kerberos deployment
> for other purposes.
>
>> additional challenge. This is because, with some RSVP messages  
>> such as a Path message, an RSVP router does not know the RSVP next  
>> hop for that message at the time of forwarding it. In fact, part  
>> of the role of a Path message is precisely to discover the RSVP  
>> next hop (and to dynamically re-discover it when it changes, say  
>> because of a routing change). Hence, the RSVP router may not know  
>> which security association to use when forwarding such a message.  
>> This applies in particular to the case where RSVP Authentication  
>> mechanisms are to be used for protection of RSVP E2E messages  
>> (e.g. E2E Path) while they transit through an aggregation region  
>> and where the dynamic Deaggregator determination procedure defined  
>> in [RSVP-AGG] is used. This is because the Aggregator and the  
>> Deaggregator behave as RSVP neighbors for the E2E reservation,  
>> while there may be one or more IP hops in between them, and the  
>> Aggregator does not know ahead of time which router is going to  
>> act as the Deaggregator.
>>
>> multiple RSVP neighbors, manual key distribution may be used. In  
>> the future, automated key distribution techniques suitable for  
>> this situation may become available. Possible examples include the  
>> developed by the IETF MSEC Working Group or those commonly used  
>> for Multicast key distribution in WiFi environments, to this  
>> scenario wherein the same key also needs to be dynamically  
>> distributed to multiple routers of a particular community (i.e.  
>> the RSVP routers here). Specification of such automated key  
>> distribution techniques or of their applicability to RSVP is out  
>> of the scope of this document.
>
> Because this usage of RSVP is not limited to IP multicasting
> and because there is not normally any IP multicast group that would
> contain the entire set of applicable RSVP neighbours, it is not at all
> clear that work from the multicast key management world could be
> adapted for use with RSVP when non-multicast flows are the
> subject of the RSVP reservations.

The sentence above was meant to give examples of where the future  
solutions might come from (ie suggest avenues of investigation to  
curious readers) as opposed to really state that those will be the  
solutions, or even that it is possible.
The perception that MSEC approaches could be adapted to the RSVP  
requirement was based on the assumption/hope that the mechanism to  
dynamically distribute the keys to the multicast receivers was not  
hardwired to the multicast group itself (so that the dynamic  
distribution of the key to all receivers could be used for other  
purposes).

But this is really beyond the scope of this document, so we could  
either:
1) tone down the current text into something like :
" In the future, automated key distribution techniques suitable for  
this situation may become available. A potential avenue of  
investigation for developing such key distribution technique could be  
to look into adapting multicast key management techniques such as  
those developed by the IETF MSEC Working Group or those commonly used  
for Multicast key distribution in WiFi environments, to the scenario  
of concern here wherein the same key also needs to be dynamically  
distributed to multiple routers of a particular community (i.e. the  
RSVP routers here). Specification of such automated key distribution  
techniques or of their applicability to RSVP is out of the scope of  
this document.
"
or
2) eliminate the sentence about MSEC work so it would simply read:
" In the future, automated key distribution techniques suitable for  
this situation may become available. Specification of such automated  
key distribution techniques or of their applicability to RSVP is out  
of the scope of this document."

Either works for me. I'd say:
If it is obvious to the security experts community that adapting MSEC  
work to this problem is a dead-end, then we should go for 2).
If we're not sure, perhaps 1) provides useful hints to the community.

Which is it?

>
> If the authors mean that IETF MSEC or some other multicast key
> management technique could be useful only when RSVP is used with
> multicast flows (as different from unicast flows), maybe that
> could be made more clear in the above text.  If they think that
> MSEC is applicable to RSVP when used with unicast flows, maybe
> they could briefly explain why they think that might be feasible.
>
>> The RSVP Authentication mechanisms do not provide confidentiality.  
>> If confidentiality is required, IPsec ESP [IPSEC-ESP] may be used,  
>> although it imposes the burden of key distribution. It also faces  
>> the additional issue discussed for key management above in case  
>> there can be IP hops in between RSVP hops. In the future,  
>> confidentiality solutions may be developed for the case where  
>> there can be IP hops in between RSVP hops, perhaps by adapting  
>> confidentiality solutions developed by the IETF MSEC Working  
>> Group. Such confidentiality solutions for RSVP are outside the  
>> scope of this document.
>>
>> Authentication. Since generic aggregate reservations are intended  
>> to reserve resources collectively for a whole set of users or  
>> hosts, malicious snooping of the corresponding RSVP messages could  
>> provide more traffic analysis information than snooping of an E2E  
>> traffic analysis is required. This approach could be used inside  
>> the aggregation region for protection of the generic aggregate  
>> reservations. It may also be used outside the aggregation region  
>> for protection of the E2E reservation. However, it is not  
>> applicable to the protection of E2E reservations while the  
>> corresponding E2E RSVP messages transit through the aggregation  
>> region.
>>
>> When generic aggregate reservations are used for aggregation of  
>> E2E reservations, the security considerations discussed in [RSVP- 
>> AGG] apply and are revisited here.
>>
>> excess of bandwidth may result in a denial of service. These  
>> issues are not confined to the extensions defined in the present  
>> document: RSVP itself has them. However, they may be exacerbated  
>> here by the fact that each aggregate reservation typically  
>> facilitates communication for many sessions. Hence compromising  
>> one such aggregate reservation can result in more damage than  
>> compromising a typical E2E reservation. Use of the RSVP  
>> Authentication mechanisms to protect against such attacks has been  
>> discussed above.
>>
>> messages that traverse an aggregation region. Malicious  
>> modification of the IP protocol number in a Path message would  
>> cause the message to be ignored by all subsequent RSVP devices on  
>> its path, preventing reservations from being made. It could even  
>> be possible to correct the value before it reached the receiver,  
>> making it difficult to detect the attack. Note that in theory, it  
>> might also be possible for a node to modify the IP protocol number  
>> for non-RSVP messages as well, thus interfering with the operation  
>> of other protocols. One way to mitigate the risks of malicious  
>> modification of the IP protocol number is to use an IPsec  
>> authentication header, which would ensure that malicious  
>> modification of the IP header is detected. This is a desirable  
>> approach but again imposes some administrative burden in the form  
>> of key management for authentication purposes and may again face  
>> the additional key management issue discussed above where there  
>> protocol number SHOULD NOT be made available
>
> The discussion in RFC-2747, Section 1.2 seems to suggest that it is
> not possible to use the IP Authentication Header with RSVP messages,
> which seems a bit contradictory to the above discussion.

So let's remove the statement on AH, so it would read:
"
An additional security consideration specific to RSVP aggregation  
involves the modification of the IP protocol number in RSVP Path  
messages that traverse an aggregation region. Malicious modification  
of the IP protocol number in a Path message would cause the message  
to be ignored by all subsequent RSVP devices on its path, preventing  
reservations from being made. It could even be possible to correct  
the value before it reached the receiver, making it difficult to  
detect the attack. Note that in theory, it might also be possible for  
a node to modify the IP protocol number for non-RSVP messages as  
well, thus interfering with the operation of other protocols. It is  
RECOMMENDED that implementations of this specification only support  
modification of the IP protocol number for RSVP Path, PathTear, and  
ResvConf messages. That is, a general facility for modification of  
the IP protocol number SHOULD NOT be made available.
"

Thanks

Francois

>> messages that traverse an aggregation region. Malicious  
>> modification of the IP protocol number in a Path message would  
>> cause the message to be ignored by all subsequent RSVP devices on  
>> its path, preventing reservations from being made. It could even  
>> be possible to correct the value before it reached the receiver,  
>> making it difficult to detect the attack. Note that in theory, it  
>> might also be possible for a node to modify the IP protocol number  
>> for non-RSVP messages as well, thus interfering with the operation  
>> of other protocols. One way to mitigate the risks of malicious  
>> modification of the IP protocol number is to use an IPsec  
>> authentication header, which would ensure that malicious  
>> modification of the IP header is detected. This is a desirable  
>> approach but again imposes some administrative burden in the form  
>> of key management for authentication purposes and may again face  
>> the additional key management issue discussed above where there  
>> protocol number SHOULD NOT be made available

>
>> Network operators deploying routers with RSVP aggregation  
>> capability should be aware of the risks of inappropriate  
>> modification of the IP protocol number and should take appropriate  
>> steps (physical security, password protection, etc.) to reduce the  
>> risk that a router could be configured by an attacker to perform  
>> malicious modification of the protocol number.
>>

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 15 Dec 2006 09:21:35 +0100

Hi Ran,

>> " In the future, automated key distribution techniques suitable  
>> for this situation may become available. A potential avenue of  
>> investigation for developing such key distribution technique could  
>> be to look into adapting multicast key management techniques such  
>> as those developed by the IETF MSEC Working Group or those  
>> commonly used for Multicast key distribution in WiFi environments,  
>> to the scenario of concern here wherein the same key also needs to  
>> be dynamically distributed to multiple routers of a particular  
>> community (i.e. the RSVP routers here). Specification of such  
>> automated key distribution techniques or of their applicability to  
>> RSVP is out of the scope of this document.
>> "
>> or
>> " In the future, automated key distribution techniques suitable  
>> for this situation may become available. Specification of such  
>> automated key distribution techniques or of their applicability to  
>> RSVP is out of the scope of this document."
>
> I'd suggest something more like this, please review and comment:
>
> 	"For situations where RSVP is being used for multicast flows,
> 	it might in future be possible to adapt a multicast key
> 	management method (e.g. from IETF Multicast Security Working
> 	Group) for key distribution with such multicast RSVP usage.
> 	For situations where RSVP is being used for unicast flows
> 	within a single administrative domain, the Kerberos technique
> 	described in Section 7 of RFC-2747 might be considered.  For
> 	situations where RSVP is being used for unicast flows across
> 	domain boundaries, it is not currently clear how one might provide
> 	automated key management.  Specification of a specific
> 	automated key management technique is outside the scope of
> 	this document.  Operators should consider these key management
> 	issues when contemplating deployment of this specification."
>

This works for me. Thank you.

Francois

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 15 Dec 2006 09:32:20 +0100

Hello,

So just to wrap up, here is the updated text for the Security section  
of draft-ietf-tsvwg-rsvp-ipsec.

Francois

When the same RSVP Authentication shared key is to be shared among  
multiple RSVP neighbors, manual key distribution may be used. For  
situations where RSVP is being used for multicast flows, it might  
also be possible, in the future, to adapt a multicast key management  
method (e.g. from IETF Multicast Security Working Group) for key  
distribution with such multicast RSVP usage. For situations where  
RSVP is being used for unicast flows within a single administrative  
domain, the Kerberos technique described in Section 7 of RFC-2747  
might be considered.  For situations where RSVP is being used for  
unicast flows across domain boundaries, it is not currently clear how  
one might provide automated key management.  Specification of a  
specific automated key management technique is outside the scope of  
this document. Operators should consider these key management issues  
when contemplating deployment of this specification.

Begin forwarded message:

> From: Francois Le Faucheur IMAP <[email-masked]>
> Date: 14 December 2006 10:28:51 GMT+01:00
> To: tsvwg tsvwg <[email-masked]>
> Cc: RJ Atkinson <[email-masked]>, Magnus Westerlund  
> <[email-masked]>
> Subject: Re: [Tsvwg] Re: IETF LC comments on draft-ietf-tsvwg-rsvp- 
> ipsec
>
> All,
>
> Below is a proposal for a considerably expanded Security Section  
> for draft-ietf-tsvwg-rsvp-ipsec, based on our earlier discussions  
> and input from Ran.
> Please comment by X-mas as I'd like to post an updated version  
> round then, and this is the only remaining open issue.
>
> Thanks
>
> Francois
>
> and admission control mechanisms, the RSVP Authentication  
> mechanisms defined in [RSVP-CRYPTO1] and [RSVP-CRYPTO2] may be  
> used. These protect RSVP message integrity hop-by-hop and provide  
> node authentication as well as replay protection, thereby  
> protecting against corruption and spoofing of RSVP messages. These  
> hop-by-hop integrity mechanisms can be naturally used to protect  
> the RSVP messages used for generic aggregate reservations and to  
> protect RSVP messages used for E2E reservations outside the  
> aggregation region. These hop-by-hop RSVP integrity mechanisms can  
> also be used to protect RSVP messages used for E2E reservations  
> when those transit through the aggregation region. This is because  
> the Aggregator and Deaggregator behave as RSVP neighbors from the  
> viewpoint of the E2E flows (even if they are not necessarily IP  
> neighbors).
>
> distribution can be used. However, existing key distribution  
> protocols may not be appropriate in all environments because of the  
> complexity or operational burden they involve. Finally, [RSVP- 
> CRYPTO1] specifies how Kerberos [KERBEROS] may be used to generate  
> the RSVP Authentication keys. Kerberos allows for the use of  
> trusted third party keying relationships between security  
> principals (RSVP sender and receivers) where the Kerberos key  
> distribution center (KDC) establishes an ephemeral session key to  
> be shared between RSVP sender and receivers.
>
> as a Path message, an RSVP router does not know the RSVP next hop  
> for that message at the time of forwarding it. In fact, part of the  
> role of a Path message is precisely to discover the RSVP next hop  
> (and to dynamically re-discover it when it changes, say because of  
> a routing change). Hence, the RSVP router may not know which  
> security association to use when forwarding such a message. This  
> applies in particular to the case where RSVP Authentication  
> mechanisms are to be used for protection of RSVP E2E messages (e.g.  
> E2E Path) while they transit through an aggregation region and  
> where the dynamic Deaggregator determination procedure defined in  
> [RSVP-AGG] is used. This is because the Aggregator and the  
> Aggregator does not know ahead of time which router is going to act  
> as the Deaggregator.
>
> the future, automated key distribution techniques suitable for this  
> here). Specification of such automated key distribution techniques  
> or of their applicability to RSVP is out of the scope of this  
> document.
>
> confidentiality solutions may be developed for the case where there  
> can be IP hops in between RSVP hops, perhaps by adapting  
> confidentiality solutions developed by the IETF MSEC Working Group.  
> Such confidentiality solutions for RSVP are outside the scope of  
> this document.
>
> typical E2E reservation. Use of the RSVP Authentication mechanisms  
> to protect against such attacks has been discussed above.
>
> its path, preventing reservations from being made. It could even be  
> possible to correct the value before it reached the receiver,  
> the additional key management issue discussed above where there can  
> be IP hops in between RSVP neighbors. It is RECOMMENDED that  
>> 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:
>> > "
>> RSVP-E2E-IGNORE) which are specified in details in RFC3175 and  
>> only brought into our document by reference to RFC3175.
>> >> legitimate participating routers, so one can pre-position  
>> manual keys
>> 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.
>>
>> applicability of RSVP Authentication seems beyond the scope of  
>> this particular document.
>>
>> that the aggregation mechanisms used here rely on the Aggregator  
>> to send an E2E Path message into the Aggregation region without  
>> 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.
>>

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 14 Dec 2006 12:58:28 -0500

On  14 Dec 2006, at 11:35, Francois Le Faucheur IMAP wrote:
> of other protocols. It is RECOMMENDED that implementations of this  
> specification only support modification of the IP protocol number  
> for RSVP Path, PathTear, and ResvConf messages. That is, a general  
> facility for modification of the IP protocol number SHOULD NOT be  
> made available.
> "

That seems better to me, given what RFC-2747 says.

Ran
[email-masked]