Subject: [MSEC] IPsec multicast extensions issues -- consensus needed!

From: Brian Weis <[email-masked]>
Date: Thu, 17 Nov 2005 23:31:36 -0800

This message follows up the IPsec multicast extensions draft discussion 
at the IETF 64 MSEC meeting: 
http://www.securemulticast.org/IETF-64/IETF64_IPsec_multicast_ext.pdf

Four scope issues were identified at that meeting. They are reproduced 
here with the summary of the discussion at the meeting.

Issue 1: Goal of this document.

The root question is how far into key management should an IPsec 
multicast extensions architecture document have? The guidance given was 
that the document should discuss key management no more than rfc2401bis 
discusses IKEv2.

Issue 2: GCKS deployments.

Should the document mandate multiple GCKS device be defined in this 
architecture? The guidance given was that this should be in a separate 
document. Also, the guidance from Issue 1 implies that this would not be 
in scope.

Issue 3: Composite cryptographic groups

The root question here is whether or not IPsec systems conforming with 
the IPsec multicast extensions should be required to replicate a packet 
if two sets of policy matched that packet. Examples of when it may be 
advantageous for two sets of policy to match a single packet would be:

a) During a policy upgrade of group members where different group 
members might have old or new policy.

b) If two heterogeneous sets of clients are part of the same group, each 
of which requires a different set of policy.

No guidance was given during the IETF 64 meeting, so a discussion is 
required on this in order to get consensus. Rather than try to discuss 
the pros and cons here, I will express one point of view in a separate 
email, and expect that George Gross will express an alternate viewpoint.

Issue 4: GKMS/IPsec interface

There was a question as to what the Group Key Management System 
interface to IPsec should be, and how much this document should cover. I 
  believe we achieved consensus in a recent email thread that the 
interface should be to define a set of new IPsec attributes with which 
GKMS' and IPsec systems need to be concerned.

It would be helpful to hear additional views on the mailing list to 
ensure we reach a consensus on these issues.

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