Subject: [MSEC] Case clarifications on group neighborship defined in draft-liu-gdoi-extensions-00.txt

From: Liu Ya <[email-masked]>
Date: Mon, 16 Oct 2006 20:32:37 +0800

Hi all,

Following are some case clarifications on NEIGHBORSHIP-NOTIFY and
GROUPKEY-SHARE exchanges defined in
http://www.ietf.org/internet-drafts/draft-liu-gdoi-extensions-00.txt. 

For a GDOI group, a member may be shortly offline with GCKS for some
reasons, such as rebooting, network route flapping, etc. During that
interval, the GCKS might either create and push new rekeying messages, or do
nothing. When the unlucky member is online again, it does not know what
happened. For assurance, it should contact the GCKS to see whether the group
SAs (including data security SA and Re-key SA) have been updated. If yes, it
must initiate another two-party exchange with the GCKS to download the
latest SAs. In some environments (e.g. OSPF router groups), it is usual that
group members happen to be offline shortly. If the group size is large, the
GCKS would have to expend much computation power and network bandwidth to
deal with members' requests. 

For some GDOI groups like an OSPF router group, a trust and stable group
membership exists. That characteristic can be utilized to alleviate GCKS's
workload: Firstly, group neighborship is established. Then, whenever a group
member is not sure whether its local SAs are in synchronization with GCKS,
it first contacts its neighbors, not GCKS. By this method, the requests from
members to GCKS decrease greatly. The neighborship can be either manually
configured on group members side, or centrally managed at GCKS. If the
second method is used, the neighborship is notified to the involved members
using the NEIGHBORSHIP-NOTIFY Exchange. Another exchange, GROUPKEY-SHARE, is
used by group members to contact its neighbors for latest group SAs. How to
establish the group neighborship is out of the doc's scope, determined by
particular group policy. 

Any comments and questions would be appreciated.

Thanks,
Liu Ya

_______________________________________________
MSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/msec

---

From: Mark Baugher <[email-masked]>
Date: Mon, 16 Oct 2006 11:43:26 -0700

Dear Liu Ya,

> http://www.ietf.org/internet-drafts/draft-liu-gdoi-extensions-00.txt.

I have questions about whether the current definitions (i.e. RFC  
3547) don't meet your requirements.  For example, do we really need a  
"unicast-groupkey-push" given that the current groupkey-push can be  
either sent either multicast or unicast?
> deal with members' requests.

Why use a centralized GCKS?  I can think of cases where a central  
GCKS is appropriate, but maybe the OSPF router groups application is  
not one of those cases.  In this case, I would go to a distributed  
GCKS model where each GDOI member runs its own GCKS (e.g. to manage  
the decryption keys for data that it sends and to forward other  
senders' decryption keys that happen to be in the cache).
> it first contacts its neighbors, not GCKS.

Why not contact the neighbor's GCKS to get the update from its cache?

> By this method, the requests from
> members to GCKS decrease greatly.

The requests to a central GCKS would decrease greatly.  What is  
increasing are requests made to other group members.  Properly  
considered, each group member can and should runs a GCKS and this is  
what gets contacted.  By this method, the requests from one member to  
abother's GCKS increases as requests to a central GCKS are reduced.

> The neighborship can be either manually

I think I understand your goal here.  And I think that you need to  
apply RFC 3547 such that each group member has a GCKS, which can act  
as a server to a GCKS client or as a client to a GCKS server.  I do  
think that you will need to describe how this would work for OSPF,  
but this maybe could be done as an Informational RFC, which is a very  
fast way to publish a standard - provided that the RFC Editor and the  
IESG agree with using RFC 3547 and your enhancements for OSPF router  
groups.  Personally, I really don't know enough to say one way or the  
other.
> Any comments and questions would be appreciated.

I hope my comments are helpful.

cheers, Mark

---

From: Mark Baugher <[email-masked]>
Date: Mon, 16 Oct 2006 11:43:26 -0700

Dear Liu Ya,

cheers, Mark

---

From: Liu Ya <[email-masked]>
Date: Tue, 17 Oct 2006 12:56:07 +0800

Hi Mark,

My answer is inline.

> either sent either multicast or unicast?

The UNICAST-GROUPKEY-PUSH, a two-party exchange, is to reliably deliver
keying messages over unicast channel. It is different from unicast
GROUPKEY-PUSH, which must be used with additional reliable transport
technology (e.g. FEC encoding) to achieve reliable rekeying.  I explained
the requirement of UNICAST-GROUPKEY-PUSH in another e-mail to George as
follows: 

For existing reliable rekeying methods, e.g., reliable multicast protocol,
FEC encoding scheme, etc., high efficiency can be achieved when they are
implemented over IP multicast. But IP multicast service is not always
available. And unicast is not fit for above methods. A multicast-undependent
way of reliable rekeying is needed. The UNICAST-GROUPKEY-PUSH exchange is to
fulfil that requirement. 

> senders' decryption keys that happen to be in the cache).

Distributed GCKS is fine. It is necessary for large GDOI groups, e.g.
large-scale OSPF ASes with thousands of routers. I imagine two deployment
models as fowllows:

                              +----------+        
                              |  GCKS |
                              +----------+
                                     ^
                                     | OOB communication mechanism
                                    V
        +---------------------+-------------------+
         |                           |                          |
        V                         V                        V
  +-------------+      +------------+      +------------+     
  | Delegate |        | Delegate|       | Delegate|
  +-------------+      +------------+      +------------+
                                     |                     
                                    V  GROUPKEY-PULL or GROUPKEY-PUSH
        +---------------------+-------------------+  
         |                           |                          |
        V                         V                        V
  +------------+      +------------+      +------------+     
  | Member |        | Member |       | Member |
  +------------+      +------------+      +------------+

or 

           OOB communication mechanism
        +---------------------+-------------------+
         |                           |                          |
        V                         V                        V
  +-------------+      +------------+      +------------+ 
  |  S-GCKS |       | M-GCKS|       | S-GCKS |
  +-------------+      +------------+      +------------+
                                     |
                                    V  GROUPKEY-PULL or GROUPKEY-PUSH
        +---------------------+-------------------+ 
         |                           |                          |
        V                         V                        V
  +------------+      +------------+      +------------+     
  | Member |        | Member |       | Member |
  +------------+      +------------+      +------------+

Here the prefix 'M-' indicates master, and 'S-' indicates subordinate. In
both forms above, the group root key must be managed centrally. And some
out-of-band mechanisms must be defined to transport that key, and other
information, between GCKSes, or between GCKS and Delegates. Obviously, the
system is complicated in above models. And side effects (e.g. larger
rekeying delay) exist. For large groups, distributed control model would be
the only standby choice. While for cases of medium scale groups, one
centralized GCKS would be enough for group keying purpose if measures are
taken to reduce GCKS's workload. Sharing keying messages between group
members is just an examplle of that measure. It is deployed as follows:

                              +----------+        
                              |  GCKS |
                              +----------+
                                     ^
                                     | GROUPKEY-PULL or GROUPKEY-PUSH
                                    V  
        +------------------------------------------------------+  
         |
|
        V
V
  +------------+
+------------+     
  | Member |   <----GROUPKEY-SHARE----> | Member |
  +------------+
+------------+

This technique can also be used in distributed control model to reduce
delegate workload, thus decreasing the number of delegates.

> > membership exists. That characteristic can be utilized to 
> alleviate  
> > GCKS's

The performance bottleneck of group keying is in GCKS, not group members.
The GROUPKEY-SHARE exchange alliviates GCKS workload by apportioning it to
group members. KEKs and TEK are still centrally managed on GCKS. Keying
messages also originate from GCKS. What a group member needs to do is to
cache the rekeying messages and send them to requesters. It does not play
the real GCKS role. 

> > second method is used, the neighborship is notified to the 
> involved  
> > members

Certainly, your comments are helpful to me.

Best regards,
Liu Ya

---

From: Liu Ya <[email-masked]>
Date: Tue, 17 Oct 2006 12:56:07 +0800

Hi Mark,

My answer is inline.

                              +----------+        
                              |  GCKS |
                              +----------+
                                     ^

or 

                              +----------+        
                              |  GCKS |
                              +----------+
                                     ^

Best regards,
Liu Ya

---

From: Vincent Roca <[email-masked]>
Date: Tue, 17 Oct 2006 10:08:05 +0200

Hello Liu,

> way of reliable rekeying is needed. The UNICAST-GROUPKEY-PUSH exchange is to

Just one small remark: reliable multicast protocols (either NORM or ALC) and
the associated FEC encoding schemes (usually embedded in the above 
protocols)
are not limited to multicast-enabled networks. Using ALC or NORM for
point-to-point communications (or any flavor of application-level 
multicast based
on underlying unicast transmissions) is fine as well. For instance, with 
ALC you
can have a periodic delivery of the content to the single receiver with 
a very limited
additional complexity. And if it turns there are many receivers, you 
won't have
to change the specifications.
Yet I admit that using NORM for point-to-point communications would add
a significant complexity for a very small benefit (if any!). That's 
perhaps what
you meant?
Having said that, there are perhaps other features (that I don't know) 
in your target
use case that make the above protocols undesirable.

Cheers,

    Vincent

---

From: Vincent Roca <[email-masked]>
Date: Tue, 17 Oct 2006 10:08:05 +0200

Hello Liu,

Cheers,

    Vincent

---

From: Liu Ya <[email-masked]>
Date: Tue, 17 Oct 2006 17:03:14 +0800

Hi Vincent,

There is difference in our understanding of "unavailability of IP multicast
service". Yes, higher level multicast services (e.g. IP multicast and
application-level multicast) are not limmited to lower level
multicast-enabled networks. But they are unnecessarily deployed. GDOI runs
on top of UDP. Availability of IP multicast service is the pre-condition of
running reliable multicast protocols such as NORTM and ALC. However, IP
multicast is seldom deployed in real networks. 

Regards,
Liu Ya 

> -----Original Message-----
> From: Vincent Roca [mailto:[email-masked]] 
> Sent: Tuesday, October 17, 2006 4:08 PM
> To: Liu Ya
> Cc: 'Mark Baugher'; [email-masked]
> Subject: Re: [MSEC] Case clarifications on group neighborship 
> defined indraft-liu-gdoi-extensions-00.txt
> 
> Hello Liu,
>

---

From: Liu Ya <[email-masked]>
Date: Tue, 17 Oct 2006 17:03:14 +0800

Hi Vincent,

Regards,
Liu Ya

---

From: Vincent Roca <[email-masked]>
Date: Tue, 17 Oct 2006 11:42:57 +0200

Hello Liu,

> multicast is seldom deployed in real networks. 
As a FLUTE/ALC and NORM developper (http://planete-bcast.inrialpes.fr), 
I can
promise you that our implementation (and the same is true for that of 
Univ. of
Tempere) supports both unicast or multicast services (whether they are 
emulated
at application level or rely on native multicast routing). Specifying a 
unicast destination
address is not a problem at all. Having purely unidirectional physical 
networks
is not a problem either with ALC (but is an issue with NORM). What I 
mean is
that we have a lot of flexibility here, and that's the reason why ALC is 
used in
many different use cases, from Internet communications (with/without 
multicast
routing), satellite based networks, and DVB-H (and similar) broadcasting 
networks.

But I don't know the GDOI use case, and cannot answer if in that 
particular use case,
it makes sense or not to use one of the reliable multicast protocols in 
all situations,
in particular when there's a single destination.

Hope it clarifies my previous email.

Cheers,

   Vincent

---

From: Vincent Roca <[email-masked]>
Date: Tue, 17 Oct 2006 11:42:57 +0200

Hello Liu,

Cheers,

   Vincent

---

From: Mark Baugher <[email-masked]>
Date: Tue, 17 Oct 2006 06:52:48 -0700

Liu Ya,

On Oct 17, 2006, at 2:03 AM, Liu Ya wrote:

> on top of UDP.

GDOI could also run on TCP if one were to define this behavior.   
Please bear in mind that RFC 3547 is based on RFC 2408, ISAKMP, which  
is designed to run over a sockets interface, not just UDP.

cheers, Mark
> Availability of IP multicast service is the pre-condition of

---

From: Mark Baugher <[email-masked]>
Date: Tue, 17 Oct 2006 06:52:48 -0700

Liu Ya,

cheers, Mark

---

From: Mark Baugher <[email-masked]>
Date: Tue, 17 Oct 2006 10:02:45 -0700

hi Vincent,

On Oct 17, 2006, at 2:42 AM, Vincent Roca wrote:

> As a FLUTE/ALC and NORM developper (http://planete- 
> bcast.inrialpes.fr), I can
> promise you that our implementation (and the same is true for that  
> of Univ. of
> Tempere) supports both unicast or multicast services (whether they  
> are emulated
> at application level or rely on native multicast routing).  
> Specifying a unicast destination
> address is not a problem at all. Having purely unidirectional  
> physical networks
> is not a problem either with ALC (but is an issue with NORM). What  
> I mean is
> that we have a lot of flexibility here, and that's the reason why  
> ALC is used in
> many different use cases, from Internet communications (with/ 
> without multicast
> routing), satellite based networks, and DVB-H (and similar)  
> broadcasting networks.
>
> it makes sense or not to use one of the reliable multicast  
> protocols in all situations,

First, we have the problem of securing reliable multicast protocols  
and what to use for key establishment.  As far back as 1998, we  
wanted to support security for reliable multicast protocols.  By "we"  
I mean IRTF SMuG.  GDOI can do that.

For this reason, we often don't have the luxury of using a reliable  
multicast service, but opt to build the mechanisms into the protocol  
that we need.  In Liu Ya's case, I think he just needs to use TCP as  
a transport protocol.

Cheers, Mark

---

From: Mark Baugher <[email-masked]>
Date: Tue, 17 Oct 2006 10:02:45 -0700

hi Vincent,

Cheers, Mark

---

From: Mark Baugher <[email-masked]>
Date: Tue, 17 Oct 2006 07:08:10 -0700

hi Liu Ya,

On Oct 16, 2006, at 9:56 PM, Liu Ya wrote:

> keying messages over unicast channel.

Why not signal that you're using TCP and not UDP for the groupkey- 
push rather than invent new protocols?

> It is different from unicast
> available.

I don't see what this has to do with the issue of reliable vs  
unreliable messaging.  We can run either UDP or TCP to a unicast  
address regardless of the availability of multicast routing and  
access services.

> And unicast is not fit for above methods. A multicast-undependent

I believe that you are equating unicast with reliable and not  
multicast.  But unicast and gdoi messaging can be run over a reliable  
end-to-end protocol such as UDP.  I don't see why we need to have a  
new elements of procedure like unicast-groupkey-push.

> large-scale OSPF ASes with thousands of routers. I imagine two  

Sorry, I'm having trouble reading this diagram.

How about a third category 'P-' indicates a peer, i.e. the gcks  
operates entirely symmetrically with necessarily having a  
hierarchical relationship at all.

> information, between GCKSes, or between GCKS and Delegates.

Why out of band?

> Obviously, the

The model that I have in my head is very much like other client/ 
server messaging protocol where each entity is both a client and a  
server.  I think that there is not necessarily any need to add new  
protocol procedures to gain the scalability - and relilability - that  
you're seeking.

> The performance bottleneck of group keying is in GCKS, not group  

Then run the GCKS from each group member.

> group members.

I don't see why we need a new protocol operation to accomplish this.

> KEKs and TEK are still centrally managed on GCKS. Keying

If a and b are members of secure group g, then either a or b or both  
may be authorized to hand out keys for g.  You're problem is not a  
lack of protocol operations, just policy.

> Certainly, your comments are helpful to me.

Great.

Cheers, Mark

---

From: Mark Baugher <[email-masked]>
Date: Tue, 17 Oct 2006 07:08:10 -0700

hi Liu Ya,

Why out of band?

Great.

Cheers, Mark

---

From: Liu Ya <[email-masked]>
Date: Wed, 18 Oct 2006 11:31:31 +0800

Hi Mark,

> On October 17, 2006 10:08 PM, Mark wrote:
> 
> hi Liu Ya,
> 

It is the first time that I know TCP can be used for GDOI. RFC3547 doesn't
say that at all. I'll consider GDOI over TCP.  And UNICAST-GROUPKEY-PUSH may
be deleted from my draft in future. Let's stop talking about that exchange
any more. 

> Sorry, I'm having trouble reading this diagram.

The diagrams is to show the hierarchy of GDOI groups when distributed GCKS
is used.

> > both forms above, the group root key must be managed 
> centrally. And  
> > some

Those mechanisms are not defined in RFC3547. I think they should be defined
by particular GDOI implementations. So, they are thought out of band.

> protocol procedures to gain the scalability - and 

The name of P2P messaging may be more appropriate than client/server. In
fact, that idea came from BitTorrent, a well-known P2P software. It is to
make one GCKS serve more group members. I don't know why you think it is not
needed for GDOI. 

> Then run the GCKS from each group member.

No GCKS exists in a GROUPKEY-SHARE exchange. Only rekeying messages, not
group key, is shared. A group member needn't provide keying service for its
neighbors. Maybe the GROUPKEYINGMESSAGE-SHARE name is more comprehensive
than GROUPKEY-SHARE.

> lack of protocol operations, just policy.

GROUPKEY-SHARE does not work in that way as you said. Only the centralized
GCKS is authorized to hand out keys for the group. Neither a nor b is
authorized to do that work. Only after a and b are assigned into one
neighboring sub-group, they are able to share rekeying messages, not keys,
each other. If they belong to different neighboring sub-groups, sharing
messages between them is not authorized. 

Moreover, GROUPKEY-SHARE is flexible. It can be selectively depoyed int a
GDOI group both partly and globally.

Regards,
Liu Ya

> >>> using the NEIGHBORSHIP-NOTIFY Exchange. Another exchange, 
> GROUPKEY-
> >>> SHARE, is

---

From: Liu Ya <[email-masked]>
Date: Wed, 18 Oct 2006 11:31:31 +0800

Hi Mark,

Regards,
Liu Ya