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

["Kantawala, Anshul" <[e-mail]>]

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

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.

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

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