Re: [Tsvwg] Adopting draft-behringer-tsvwg-rsvp-security-groupkeying as WG item?

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

Hi Lars,

We feel that there are some holes in existing key management  
approaches for RSVP. For example, existing key management cannot be  
used when the RSVP router does not know the next RSVP router. This  
situation occurs in the presence of non-RSVP-routers and is becoming  
more and more common with RSVP Aggregation approaches (e.g. RFC3175 &  
RFC4860 when used with dynamic Deaggregator discovery, RSVP over PCN  
clouds,...). Maybe this is what you would call "TSVWG applications"  
requiring some solution.

We also feel that TSVWG should address this: at least documenting the  
holes, but also ideally facilitating development of a solution.

Would you agree with these statements?

We can discuss later whether draft-behringer is the right vehicle to  
address this, whether we should restructure it or wether we should  
tackle the problem completely differently.

Thanks

Francois

On 28 Jan 2008, at 11:26, Lars Eggert wrote:

> Hi,
>
> On 2008-1-28, at 11:59, ext Francois Le Faucheur IMAP wrote:
>> On 24 Jan 2008, at 18:04, Lars Eggert wrote:
>>
>>> (individual hat on)
>>>
>>> I'm not convinced that this document needs to be a TSVWG  
>>> document. It's an Informational document that surveys group  
>>> keying options for RSVP, and as such could be published directly  
>>> through the RFC Editor.
>>
>> I am not aware of any solution currently available from the IETF  
>> to actually deploy such distribution of group keys for RSVP.
>> This could, for example, be easily achieved with small extensions  
>> to GDOI (draft-weis-gdoi-for-rsvp), but a solution will only be  
>> defined in IETF (e.g. by MSEC) if the corresponding need is  
>> established by the TSVWG.
>
> based on the discussions in Vancouver, I thought the goal of this  
> document was to survey the options for group keying for RSVP. I  
> don't see how such a survey would motivate the need for any sort of  
> solution work. Meaning that even if this survey finds that none of  
> the existing options are always satisfactory, that's a finding that  
> to me still doesn't immediately motivate the need to develop any  
> new solution. New protocol work should be motivated by an  
> application requiring it.
>
>> So, my recommendation is that TSVWG decides whether group keying  
>> is useful for RSVP security or not, and if yes documents this  
>> decision. Making draft-behringer-tsvwg-.. a WG document seems a  
>> natural way to achieve this.
>> This is one reason why I feel draft-behringer-tsvwg should be  
>> considered for WG document.
>
> For which current work item in TSVWG would group keying be useful,  
> or rather, required? A need for a new solution needs to come from  
> an application that requires group keying. As far as I know, no  
> such application is being worked on in TSVWG.
>
>> (I certainly feel that a group keying solution for RSVP would be  
>> very useful. If some people feel that group keying for RSVP is not  
>> useful, it would be interesting to know why and how the problems  
>> solved by group keying can be addressed differently.)
>
> Lots of things are useful - what application requires group keying  
> for RSVP that goes beyond what we currently have? I'd like to  
> understand where the motivation comes from.
>
>> Another practical reason is that the issue of group keying methods  
>> for RSVP gets raised by Security experts every time there is a new  
>> RSVP-related document going to IESG Last Call. See, for example,  
>> the thread with Ran Atkinson from Dec 2006 and titled "Re: [Tsvwg]  
>> Re: IETF LC comments on draft-ietf-tsvwg-rsvp-ipsec".
>> Effectively, on request from Security experts in order to make  
>> sure the security aspects are covered appropriately, we end up re- 
>> discussing the applicability of existing keying methods +  
>> applicability of potential future group keying methods in the  
>> "Security Considerations" section of every RSVP-related document  
>> (see RFC4860, draft-ietf-tsvwg-emergency-rsvp). It is important  
>> that applicability/Pros&cons of various keying methods for RSVP be  
>> documented by TSVWG once for all. This discussion should reflect  
>> the view of the WG since it affects RSVP security across all RSVP- 
>> related documents.
>
> So this argues for extracting the repeated argument into an  
> individual draft, so it can be referenced instead of needing to be  
> duplicated. But it does not motivate the need for a new solution.
>
>> Also, draft-behringer-tsvwg proposes to document applicability of  
>> keying methods to IPsec protection of RSVP (as opposed to just  
>> RSVP authentication). We are not aware of an IETF document where  
>> this is well addressed and feel this would be useful (and has been  
>> requested by a few people e.g. Anshul from LMCO).
>
>
> Can you point me at Anhul's email, please? I couldn't dig it up  
> locally.
>
> Thanks,
> Lars