Subject: [MSEC] GDOI update document scoping questions

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 06 Apr 2006 09:54:19 -0700

<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?  What if any changes are required 
to the MSEC-IPsec extensions document due to the addition of AH support?

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

While I am on topic, do you plan to introduce capabilities like 
sender/receiver indication in GSA download?

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.

thanks and regards,
Lakshminath
</Speaking as a WG contributor>

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

---

From: Brian Weis <[email-masked]>
Date: Fri, 07 Apr 2006 16:30:33 -0700

Hi Laksminath,

Lakshminath Dondeti wrote:
> 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.

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

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

> schedule won't allow it, but will make it a higher priority next week.

That'd be great, thanks!
Brian

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