Subject: Re: [GSEC] Re: [MSEC] MSEC v01 arch, comments on section 2 (fwd)

From: Ran Canetti <[email-masked]>
Date: Mon, 30 Jun 2003 14:56:42 -0400

> From: George Gross <[email-masked]>

...

> > >   1 - For data traffic multicast, what error recovery procedure(s) are
> > > required to detect and avoid network congestion? acks/nacks? what about
> > > Explicit Congestion Notification (ECN)?
> >
> > I think this should be addressed in the to-be-released Data Transforms
> > Architecture specification.
> 
> okay, but I would like to suggest adding a pointer in that direction
> within your arch document.

The approach taken in the GKMA document is to leave this issue to the
individual key management protocols. There is a wide variety of potential
settings (dependeing on the size of the group, the expected congestion, the
ease of upstream communication, etc.), and it doesnt seem to make sense to
impose a single mechanism here.

> 
> >
> > >   3 - Should/do the group key management protocols assume an underlying
> > > reliable transport service?
> >
> > I believe the answer is that they should not assume they are available,
> > because most multicast routing mechanisms deployed today are not
> > reliable.
> >
> > My preference is for this issue to be dealt with in the GKMA document,
> > which further refines the group key management architecture.
> 
> hmmm... the GKMA document will kind of describe how the cows have already
> left the barn ;o) i.e. GSAKMP is in last call, same story with MIKEY, and
> GDOI-v1 is in the RFC queue. I would have thought one would write the GKMA
> before the protocol specs?!?
> 
> Anyway, I agree with the view you expresed above, that multicast routing
> is not reliable.  Therefore, a MSEC protocol spec must either explicitly
> define its own error procedures or point to a reliable multicast data
> transport protocol that is mandatory to implement. At this point, are
> GSAKMP and MIKEY cast in stone? Maybe GDOIv2 is the only possible
> candidate for such a solution...

Again, there is history here... the common architecture to these KM
protocols was discussed at length in smug/msec meetings. The GKMA document
is indeed progressing more slowly than ther KM protocols themselves (for
obvious reasons - people invest more time in their protocols); but the
common architecture is understood by all authors (or so I hope).

...

> > >   7 - does the architecture have a particular profile on X.509
> > > certificates that would assure interoperability (witness the discussions
> > > on IPSEC list wrt/ IKEv2 ID payloads and certs, wouldn't we like to avoid
> > > that swamp?)
> >
> > I don't think it is a goal of the architecture document to ensure
> > interoperability. It's describing the architecture at a much higher
> > level.
> 
> that implies I have to tackle each protocol spec in turn, and comb through
> it for an X.509 profile. My cursory survey of the GSAKMP spec didn't show
> anything resembling this. GDOIv1 inherits IKEv1, but I don't recall what
> it say wrt/ ID certificates in the context of groups. I'll take a look
> see...

This is indeed a good point, that should be addressed by the KM protocols.
Not at the architecture level though, I'd say... perhaps mentioned in the
GKMA level.

> 
> >
> > >   8 - what happens when the secure multicast protocols traverses an
> > > IPSEC gateway? It seems that implicitly you are defining transport mode
> > > multicast data security associations?  or could they be in tunnel mode? if
> > > the latter, then mention that and how it works.
> >
> > George, could you elaborate on the problem? I don't think it should
> > matter if a multicast protocol gets encapsulated in a transport mode or
> > tunnel mode IPsec header. If it gets sent through an IPsec gateway
> > later, and that IPsec gateway policy says to encrypt it, then it would
> > just end up with two IPsec headers, right?
> 
> It is not a problem per se, rather it is a use case: unsecure multicast
> tunnelled within secure multicast. The application that comes to mind is
> an Enterprise distributing a multicast session to its sites using secure
> multicast over the public Internet, and within each site doing regular
> multicast (i.e. trusted network inside the site).
> 
> So I think that the MSEC protocol should allow negotiation of either
> tunnel or transport mode. And the arch doc should point out this is
> required.

I'm still not sure I follow here. I guess in your example the gateways of
the varioue corporate sites would not have access to the data, ie they
would not have keys. right? so they would forward the data "opaquely" to he
recipients, regardless of the encapsulation mode.
or am i missing something?

note btw that the architecture does not mandate ip-level data protection.
potentially, the data can be protected via srtp or the like.

Ran

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 30 Jun 2003 15:13:47 -0400

"but the
common architecture is understood by all authors (or so I hope)."

Ran,

This probably should be documented in the MSEC architecture document!

I am partially to blame on the GKMA stuff, but have plans to speed it up 
by recruiting new contributors in Vienna (those who are not attending 
the meeting, please contact Brian Weis and me).  There are several teams 
presenting their work on GKMAs this time at the GSEC meeting; I plan to 
ask folks to join the GKMA standardization effort.

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 30 Jun 2003 16:37:49 -0400

Clarification:

Ran uses GKMA for GKM architecture document, whereas I was talking about 
GKM algorithms.  In future, we might use GKMarch and GKMalgm to avoid 
confusion.

cheers,
Lakshminath