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

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

Hi Hannes,

On 30 Jan 2008, at 08:12, Hannes Tschofenig wrote:

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

The context of this discussion was that draft-behringer plans to  
cover keying not just for RSVP Authentication but also for RSVP  
encryption. So I personally interpreted the statement of  "all  
aspects of RSVP" as "all aspects of RSVP in the dimension of which  
protection to apply to RSVP".

In any case, as far as relative scope of draft-behringer vs RFC4230,  
our earlier agreement was that draft-behringer would focus on key  
management and would refer to RFC4230 for all other aspects. The text  
of draft-behringer-..01 already states so. I assume we are still fine  
with this break down.

Cheers

Francois

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