Subject: [MSEC] Re: GDOI update document scoping questions

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 17 May 2006 04:33:26 -0700

It looks like I am the only one with some esoteric issues on this, so 
with the chair hat on I am going to suggest that we ignore my 
comments for the moment.  Let's make this a WG document.

Brian and Sheela, I need proposed milestones; planned date for the 
submission of the revised version, and for LC.  Please send those as 
soon as you can.  Thanks.

regards,
Lakshminath

At 04:30 PM 4/7/2006, Brian Weis wrote:
>Hi Laksminath,
>
>Lakshminath Dondeti wrote:
>><Speaking as a WG contributor>
>>Hi Brian and Sheela,
>>I raised a few questions on the scope of the GDOI Update document 
>>(3547bis?).  First, there is the issue of introducing AH support in 
>>GDOI.  I have a few questions here, first I would like the case for 
>>AH support discussed on the list, so I will ask the question again 
>>that I asked in Dallas.  Why is AH support needed?  Is 
>>ESP-NULL-Encryption not sufficient?
>
>You're really asking why AH is relevant when ESP-NULL-Encryption 
>could be used. There *is* a difference between the two, which is 
>that AH authenticates the IP header whereas ESP does not. The IPsec 
>community is used to thinking about VPN scenarios where 
>authentication of the IP addresses seems irrelevant because there 
>are just two endpoints sharing the keys anyway. However, in some 
>group applications header authentication is valuable to prove that 
>the *source* of the IP packet was not changed in transit. GDOI 
>should support AH for those applications. For example, the 
>Source-Specific Multicast architecture specification discusses the 
>risks of spoofed source addresses.
>
>Another reason to support AH is that, for better or worse, some 
>specifications dictate support for AH, and they are group 
>applications. Most notably the PIM family of multicast routing 
>protocols (PIM-DM, PIM-SM, PIM-Bidir) and OSPFv3. The protocols are 
>often keyed manually and they deserve to use a dynamic key 
>management system too! :-)
>
> > What if any changes are required to the MSEC-IPsec
> > extensions document due to the addition of AH support?
>
>Because RFC 4301 specifies AH as a valid (i.e., not deprecated) 
>IPsec protocol, the MSEC-IPsec extensions document mentions it as well.
>
>>Second, what is the scope of the GDOI update document.  Or is it 
>>open ended?  I am not really too particular about either approach 
>>(in moderation of course, we don't want to redesign GDOI, just 
>>update, hopefully with backward compatibility -- or is this is req 
>>that you have in mind?).
>
>The scope we had in mind was 1) deal with hash agility, 2) 
>clarifications to text based on implementation experience, and 3) 
>minor additions to the protocol. Backward compatibility was intended 
>if not explicitly stated.
>
>With this scope in mind, minor additions in addition to what we 
>specified in the draft that maintain backward compatibility could be 
>considered.
>
>Come to think of it, there's one other area we should add to the 
>scope. The MSEC-IPsec extension document describes some additional 
>key management attributes that would be new to GDOI.
>
>>While I am on topic, do you plan to introduce capabilities like 
>>sender/receiver indication in GSA download?
>
>If this can be done without breaking backwards compatibility, it 
>could make sense. We didn't intend to introduce it ourselves.
>
>>I think I promised to review the I-D this week, but it looks like 
>>my schedule won't allow it, but will make it a higher priority next week.
>
>That'd be great, thanks!
>Brian
>
>>thanks and regards,
>>Lakshminath
>></Speaking as a WG contributor>
>
>
>--
>Brian Weis
>Advanced Security Development, Security Technology Group, Cisco Systems
>Telephone: +1 408 526 4796
>Email: [email-masked]

_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec