[Tsvwg] Re: Draft-ietf-tsvwg-rsvp-dste-04.txt secdir review

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

Magnus, Donald and everyone,

On 30 Aug 2006, at 11:37, Magnus Westerlund wrote:

> Hi,
>
> To me this seems very reasonable. I am awaiting an update of the  
> document before progressing to IESG Evaluation.


Below is the updated text I propose to use as the updated Security  
Section. I hope this addresses the review comments received so far.  
Please let me know if you have any further comments/recommendations.  
I plan to issue in a few days a next rev as agreed so the document  
can progress to IESG Evaluation.

Thanks

Francois


"
8. Security Considerations

In the environments concerned by this document, RSVP messages are  
used to control resource reservations for E2E flows outside the MPLS  
region as well as to control resource reservations for MPLS TE  
Tunnels inside the MPLS region. To ensure the integrity of the  
associated reservation and admission control mechanisms, the  
mechanisms defined in [RSVP-CRYPTO1] and [RSVP-CRYPTO2] can be used.  
Those protect RSVP messages integrity hop-by-hop and provide node  
authentication, thereby protecting against corruption and spoofing of  
RSVP messages. These hop-by-hop integrity mechanisms can naturally be  
used to protect the RSVP messages used for E2E reservations outside  
the MPLS region, to protect RSVP messages used for MPLS TE Tunnels  
inside the MPLS region, or for both. These hop-by-hop RSVP integrity  
mechanisms can also be used to protect RSVP messages used for E2E  
reservations when those transit through the MPLS 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 nor RSVP-TE neighbors). It that case, the Aggregator and  
Deaggregator need to use a pre-shared secret.

As discussed in section 6 of [RSVP-TE], filtering of traffic  
associated with an MPLS TE Tunnel can only be done on the basis of an  
MPLS label, instead of the 5-tuple of conventional RSVP reservation  
as per [RSVP]. Thus, as explained in [RSVP-TE], an administrator may  
wish to limit the domain over which TE Tunnels (which are used for  
aggregation of RSVP E2E reservations as per this specification) can  
be established. See section 6 of [RSVP-TE] for a description of how  
filtering of RSVP messages associated with MPLS TE Tunnels can be  
deployed to that end.

This document is based in part on [RSVP-AGG] which specifies  
aggregation of RSVP reservations. Section 5 of [RSVP-AGG] raises the  
point that because many E2E flows may share an aggregate reservation,  
if the security of an aggregate reservation is compromised, there is  
a multiplying effect in the sense that it can in turn compromise the  
security of many E2E reservations whose quality of service depends on  
the aggregate reservation. This concern applies also to RSVP  
Aggregation over TE Tunnels as specified in the present document.  
However, the integrity of MPLS TE Tunnels operation can be protected  
using the mechanisms discussed in the previous paragraphs. Also,  
while [RSVP-AGG] specifies RSVP Aggregation over dynamically  
established aggregate reservations, the present document restricts  
itself to RSVP Aggregation over pre-established TE Tunnels. This  
further reduces the security risks.

In the case where the Aggregators dynamically resize the TE tunnels  
based on the current level of reservation, there are risks that the  
TE tunnels used for RSVP aggregation hog resources in the core which  
could prevent other TE Tunnels from being established. There are also  
potential risks that such resizing results in significant computation  
and signaling as well as churn on tunnel paths. Such risks can be  
mitigated by configuration options allowing control of TE tunnel  
dynamic resizing (maximum TE tunnel size, maximum resizing  
frequency, ...) and/or possibly by the use of TE preemption.

Section 5 of [RSVP-AGG] also discusses a security issue specific to  
RSVP aggregation related to the necessary modification of the IP  
Protocol number in RSVP E2E Path messages that traverses the  
aggregation region. This security issue does not apply to the present  
document since aggregation of RSVP reservation over TE Tunnels does  
not use this approach of changing the protocol number in RSVP messages.

Section 7 of [LSP-HIER] discusses security considerations stemming  
from the fact that the implicit assumption of a binding between data  
interface and the interface over which a control message is sent is  
no longer valid. These security considerations are equally applicable  
to the present document.

If the Aggregator and Deaggregator are also acting as IPsec Security  
Gateways, the Security Considerations of [SEC-ARCH] apply.


"

where [RSVP-CRYPTO1] and [RSVP-CRYPTO2] refer to RFC2747 & RFC 3097




>
> cheers
>
> Magnus
>
> Francois Le Faucheur wrote:
>> Hello Don, Sam,
>> Thanks for your reviews and comments. Focusing on the Security  
>> Cons section:
>> On 9 Aug 2006, at 05:41, Eastlake III Donald-LDE008 wrote:
>>>
>>>
>>> The Security Considerations section references no less than five  
>>> other
>>> RFCs whose security sections are incorporated by reference. These  
>>> RFCs
>>> cover a wide range of IETF eras. The earliest has a Security  
>>> section but
>>> no Security Considerations section because it pre-dates the  
>>> requirement
>>> to have such a section. I doubt that the security provisions in the
>>> earlier of these RFCs would pass current standards. It is pretty  
>>> hard to
>>> see whether the security provisions in the six documents (this  
>>> draft and
>>> the 5 RFCs referenced from its Security Considerations section)  
>>> actually
>>> fit together well without substantial gaps under the many options
>>> described. It is my impression that there is probably a reasonable
>>> interpretation of these various security sections that fits  
>>> together...
>>>
>> I see your point.
>> In this light, we could change the Security Considerations section  
>> so that:
>>     - it incorporates by reference the RSVP Crypto specs (RFC2747  
>> & 3097) as the fundamental provisions for securing RSVP (I just  
>> realized those were not explicitly referenced which was a big  
>> omission)
>>     - it clarifies how the RSVP Crypto mechanisms can indeed be  
>> used in this environment between Aggregator and Deaggregator  
>> (considering those are not direct IP neighbors)
>>     - it captures the key security issue specific to RSVP-TE,  
>> points to [RSVP-TE/3209] Security Cons section for details of  
>> provisions for this, & explains that this is relevant here only  
>> for the "Aggregate RSVP reservations" ie the TE Tunnels.
>>     - it removes the reference to RSVP-AGG/3175 Sec Cons  
>> altogether and instead incorporates directly the relevant points  
>> (since only a small subset are actually relevant).
>>     - it keeps the current reference to LSP-HIER/4206 since it  
>> already spells out which consideration/provision is relevant,
>>     - it keeps the current reference to SEC-ARCH/4301 since it  
>> already spells out that this is only relevant for the special case  
>> where the Aggregator and Deaggregator are also acting as IPsec  
>> Security Gateways (ie IPsec is used between Aggregator and Deagg).
>> Does that sound like a viable way forward?
>> Thanks
>> Francois
>
>
> -- 
>
> 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]