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

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 27 Jun 2003 16:27:09 -0400

Good questions.  We sort of went away from them, didn't we?  I will take 
up some.  In my mind, stuff like NAT, IPv6 should be part of protocol 
support, and I believe GDOI has that benefit as it is based on IKEv1 (I 
am not supposed to say that;  so let that be a secret between, oh the 
hundreds of people who follow this group :-) ), which has some NAT 
support and IPv6 support.  I believe GSAKMP would work with IPv6, not 
sure about NATs though!

I haven't thought about group AH though.

In my mind the reliable transport issue has been fluid.  It ranges from 
'assume underlying reliable transport' to 'use rudimentary FEC.'  We 
have some discussion on that topic in GKMarch (I think :-) ).  Some 
GKMAs have builtin support for reliability and I think that's the best 
way to go.  We may have to add some support for sending feedback though 
(hence the I-D on feedback protection, admittedly it needs some work).

Multicast SAs use transport mode IPsec AFAIK.  With 2401bis there should 
not be any ambiguity in lookups anyway.

I would defer certs to Thomas, MSEC's resident certs expert (Verisign ;-))

cheers,
Lakshminath

George Gross wrote:
> Hi Ran,
> 
> 	inline below....
> 
> br,
> 	George
> 
> On Fri, 27 Jun 2003, canetti wrote:
> 
> 
>>George,
>>
>>Sorry for jumping into the discussion late.
>>
>>I'm very glad you brought up this point.
>>One of the main design principles of msec (coming from smug) is that the
>>security we provide should be end-to-end, and furthermore should be as
>>indepenent as possible from the underlying routing mechanism.
> 
> 
> I have not yet dredged the SMUG archives, so I don't have the benefits of
> that history. I have a hunch that in the future those readers approaching
> secure multicast for the first time would pick up this document to get
> oriented once it becomes available as an informational RFC. With that in
> mind, I notice that this is not the first time that I heard the SMUG work
> show up as the unspoken folklore of this working group ;o) IMHO, this
> document could serve well as a summary of those design decisions rather
> than be silent on them. For example, I noticed on the current FMKE thread
> that SMUG was cited for the decision not to have ack/nack in the secure
> multicast rekey protocol(s).
> 
>  >
> 
>>Protecting the routing mechanism provides "only" protection against DoS
>>(ie, it is not needed for guaranteeing secrecy or authenticity of thedata).
>>While this is a very important concern, the feeling was that this should
>>be dealt with on a different level than the basic msec goals of
>>guaranteeing secrecy and authenticity of the data.
>>
>>So, in other words, the lack of discussion of the routing mechanisms and
>>their protection is intentional.
>>
>>I'd suggest that some text clarifying this point be added to the document.
>>(The point will be elaborated on in the upcoming requirements document;
>>still it may be good to refer to it also in the architecture document.)
>>
> 
> 
> This is good. I think that text will help this document alot to the extent
> that it identifies secure multicast routing as an architectural interface
> or protocol that shows up in a comprehensive secure multicast
> architecture, and it interacts with the secure multicast membership
> controller.  The text should also indicate it is out of scope of the
> current working group but could be an area for future standardization.
> 
> 	My original e-mail that triggered this thread had a laundry list
> of 8 items, of which the multicast routing security was only one (albeit
> perhaps the most interesting). I'll re-issue that list here, sans #2 which
> we've largely answered. Comments from the list and the authors would be
> appreciated....
> 
>   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)?
> 
>   3 - Should/do the group key management protocols assume an underlying
> reliable transport service?
> 
>   4 - while this may be implied, you should indicate this architecture is
> independent of IP-v4 or IP-v6 and that the secure multicast protocols MUST
> operate with both.
> 
>   5 - how does the secure multicast architecture interact with NAT? is it
> required to work across multiple NAT boundaries? (e.g. does group AH
> break?)
> 
>   6 - does the architecture assume a single common PKI that spans all
> members of the group or shared secrets (which does not scale)?
> 
>   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?)
> 
>   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.
> 
> 
> 
>  > Hope this clarifies.
> 
>>Ran
>>
>>
>>On Wed, 25 Jun 2003, George Gross wrote:
>>
>>
>>>Hi Lakshminath,
>>>
>>>	inline below...
>>>
>>>br,
>>>	George
>>>
>>>On Wed, 25 Jun 2003, Lakshminath Dondeti wrote:
>>>
>>>
>>>>There are several old expired drafts that discussed IGMP and PIM
>>>>security.  Most of the folks in MSEC are aware of that work, yet decided
>>>>to not include protocol security in the charter.  It may belong in a
>>>>separate WG IMO (e.g., IPSEC WG designs protocols for data protection
>>>>and RPSEC discusses routing protocol protection).
>>>>
>>>><GSEC co-chair hat on>  You are welcome to bring any new ideas (or
>>>>revise old I-Ds and bring them for discussion) to the GSEC meeting; most
>>>>MSEC regulars will show up and the RG might decide how to proceed <GSEC
>>>>co-chair hat off>.
>>>
>>>regretably, I won't be in Vienna, ;o( no doubt it would be great place to
>>>visit
>>>
>>>please let me know what comes out of those discussions...
>>>
>>>
>>>>I think the MSEC architecture I-D should proceed with its current scope.
>>>
>>>I am not asking that the MSEC architecture expand its scope; rather it
>>>should be _completed_ to describe the requirement to have a mechanism/hook
>>>through which this type of information can be included/tunneled in the
>>>MSEC protocols without defining its structure or semantics (i.e.  it is
>>>opaque and to be defined). In the short term, this is likely to be as
>>>simple as reserving a TLV payload type for this future use.
>>>
>>>	In the arch ID, the text should simply acknowledge that there is a
>>>set of entities, multicast routers, that must participate in the group
>>>membership's multicast data distribution and they do so securely under the
>>>direction of the GKCS. Unlike point to point IPSEC which is independent of
>>>the routing infrastructure, in MSEC there is a concept of group membership
>>>that has a direct relationship with the multicast routing tables. The text
>>>could be written in very general terms. The text should allow the
>>>flexibility of allowing either the multicast router or the group member
>>>securely initiating the group join/leave routing table update.
>>>
>>>
>>>
>>>>regards,
>>>>Lakshminath
>>>>
>>>>George Gross wrote:
>>>>
>>>>>Hi,
>>>>>	With Mounir's permission, I'm forwarding an exchange we had wrt/
>>>>>securing IGMP/MLD/PIM as part of MSEC...
>>>>>
>>>>>	George
>>>>>
>>>>>---------- Forwarded message ----------
>>>>>Date: Wed, 25 Jun 2003 05:12:18 -0400 (EDT)
>>>>>From: George Gross <[email-masked]>
>>>>>To: [email-masked]
>>>>>Cc: George Gross <[email-masked]>
>>>>>Subject: Re: [MSEC] MSEC v01 arch, comments on section 2
>>>>>
>>>>>Hi Mounir,
>>>>>
>>>>>	My goal with the section 2 questions was to tease out some of the
>>>>>unspoken assumptions that lurk in the architecture if one were to actually
>>>>>deploy MSEC.
>>>>>
>>>>>	While Brian and Tom have yet to weigh in on this topic, I imagine
>>>>>that adding refs to the GSEC RG work is a beginning, but not all that
>>>>>needs to be said in the arch doc wrt/ to this comment. I think the
>>>>>architecture doc has to describe, and the MSEC protocols have to define an
>>>>>extensible mechanism(s) to encapsulate an opaque IGMP/MLD
>>>>>authorization/authentication information payload within the {GSAKMP, GDOI,
>>>>>whatever} key management protocol to each group member.  With this
>>>>>coupling, I think that the multicast session becomes far more secure.
>>>>>
>>>>>securing PIM or the multicast routing protocol du jour is another
>>>>>interface to MSEC that needs to be mentioned in the arch doc, and perhaps
>>>>>ultimately standardized...
>>>>>
>>>>>br,
>>>>>	George
>>>>>
>>>>>On Tue, 24 Jun 2003 [email-masked] wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hi George,
>>>>>>
>>>>>>I think that you asked very intersting questions with respect to section 2.
>>>>>>
>>>>>>For your follwong questions:
>>>>>>
>>>>>>
>>>>>>> 2 - how to assure the security of the IGMP, MLD, and the multicast
>>>>>>>routing protocol(s) like PIM?
>>>>>>>
>>>>>>
>>>>>>I think Group Membership (MLD, IGMP) security issues as well as multicast
>>>>>>routing porotocols security issues are adressed (exclusively) in GSEC RG. For
>>>>>>the security issues in multicast routing protocols, it seems that there is a
>>>>>>specific solution for each protocol.
>>>>>>
>>>>>>May be next GKarch draft can mention the drafts "draft-irtf-gsec-igmpv3-
>>>>>>security-issues-01" and "draft-irtf-gsec-pim-sm-security-issues-01" as they
>>>>>>both propose extending GDOI to secure respectively IGMP and PIM-SM.
>>>>>>
>>>>>>However, I think that securing Group membership and multicast protocol
>>>>>>protocols basing on GkmArch may not be a good thing as it makes the securty
>>>>>>solution (for MLD and IGMP ,and e.g. PIM) dependent on GKmArch . Decoupling (at
>>>>>>least partially) GkMArch form the other two issues can ensure a multi-
>>>>>>(independent)level security need.
>>>>>>
>>>>>>
>>>>>>Mounir
>>>>>>
>>>>>>-------------------------------------------------
>>>>>>Laboratoire Heudiasyc. UMR CNRS 6599
>>>>>>http://www.hds.utc.fr
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>msec mailing list
>>>>>[email-masked]
>>>>>http://www.pairlist.net/mailman/listinfo/msec
>>>>>
>>>>
>>>>
>>>
>>>_______________________________________________
>>>msec mailing list
>>>[email-masked]
>>>http://www.pairlist.net/mailman/listinfo/msec
>>>
>>
>>
>>_______________________________________________
>>msec mailing list
>>[email-masked]
>>http://www.pairlist.net/mailman/listinfo/msec
>>
> 
> 
> 

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

---

From: Brian Weis <[email-masked]>
Date: Fri, 27 Jun 2003 09:18:33 -0700

George, I wasn't ignoring your original email ... it just took awhile to
get to it, and then I enjoyed the resulting discussion. :-) Thanks to
everyone for all the good discussion on these points.

> > indepenent as possible from the underlying routing mechanism.

I believe the following statements summarize the discussion, and are
what I propose adding to the architecture document. (This is not actual
text, just the logical statements.)

1. A secure application layer group using MSEC protocols does not
require the multicast routing infrastructure to participate in the
group. However, that application layer group has no guarantee that the
the multicast routing infrastructure will route the packets
appropriately.

2. The multicast routing infrastructure comprises a group that could use
MSEC protocols to protect its own traffic. However, this would be
independent of any secure application layer groups.

I would also add:

3. The bridge between the application layer group and the multicast
routing is the network level "join" to a group. Joins to a multicast
group are not the same as "joining" a secure group. I.e., the former
involves sending an IGMP or MLD messages to the closest multicast-aware
router, and the latter means registering with a GCKS to obtain the
policy and keys necessary to participate in the group. (This is already
mentioned in section 5.2.4, but probably needs more emphasis.)

> multicast rekey protocol(s).

George makes a very valuable observation that we aren't writing
everything that we're assuming. I appreciate him pointing out where we
are doing this, because we do need to document them.

> Explicit Congestion Notification (ECN)?

I think this should be addressed in the to-be-released Data Transforms
Architecture specification.

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

> independent of IP-v4 or IP-v6 and that the secure multicast protocols MUST

Good point.

> required to work across multiple NAT boundaries? (e.g. does group AH

My usual answer to the problem of multicast and NAT is that it isn't a
problem, because the multicast routing mechanisms (e.g., PIM) rely
heavily on the source address. I'll try to find a place to say this in
the architecture document.

> members of the group or shared secrets (which does not scale)?

The answer is "no", and I'll add a discussion of this in section 5.2.4.

> on IPSEC list wrt/ IKEv2 ID payloads and certs, wouldn't we like to avoid

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.

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

Thanks,
Brian

-- 
Brian Weis
Strategic Cryptographic Development, ITD, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: George Gross <[email-masked]>
Date: Sun, 29 Jun 2003 22:13:25 -0400 (EDT)

Hi Brian,

	appreciate your rev'ing the arch doc to address my comments/Qs...

a few clarifications inline below.

br,
	George

> everyone for all the good discussion on these points.

<snip to save bandwidth>

> Architecture specification.

okay, but I would like to suggest adding a pointer in that direction
within your arch 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...

<snip>

> the architecture document.

You say that it is not a problem, but I don't share your confidance that
it works in all cases. At the private/public network boundary, would the
NAT gateway twiddle with the source IP address, and therefore break the
MAC calc for group AH?

<snip>
> interoperability. It's describing the architecture at a much higher

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

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