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

[Hannes Tschofenig <[e-mail]>]

Hi Anshul,

Kantawala, Anshul wrote:
> Lars,
> My comment about the usefulness of having a single IETF document that
> covers all aspects of RSVP security (authentication and encryption) was
> made at the Vancouver IETF meeting (name mistakenly put in as "Andrew"
> in the meeting minutes: "*Andrew - interested in RSVP authentication and
> RSVP over IPsec, and thinks this work should progress").
>   
draft-behringer-tsvwg-rsvp-security-groupkeying is certainly not the 
document that covers all aspects of RSVP security.


> A big stumbling block we have encountered in trying to propose RSVP
> signaling as a solution for government and other corporate
> secure/sensitive networks is RSVP security.  Having an IETF document
> covering RSVP security not only helps in handling such concerns, it will
> also aid in focused development of security solutions for RSVP.
>   
Have you ever read RFC 4230?


Please tell me more about corporate networks using RSVP todo QoS. I 
would like to met that company that deploys RSVP to dynamically signal 
QoS in their network.

Btw, when you make use of QoS mechanisms in a network then you 
automatically introduce more security vulnerabilities.

> Thus, I reiterate my support in making this a WG document.
>
>   

Ciao
Hannes

> Regards,
> Anshul 
>
> -----Original Message-----
> From: Lars Eggert [mailto:[e-mail]] 
> Sent: Monday, January 28, 2008 5:26 AM
> To: ext Francois Le Faucheur IMAP
> Cc: ext Magnus Westerlund; RJ Atkinson; Brian Weis; tsvwg list IETF
> Subject: Re: [Tsvwg] Adopting
> draft-behringer-tsvwg-rsvp-security-groupkeying as WG item?
>
> 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
>
>
>
>