Subject: [MSEC] Re: Reliability & Secure Multicast

From: Brian Weis <[email-masked]>
Date: Tue, 01 Jul 2003 15:06:01 -0700

Hi Gavin,

"Kenny, Gavin (Space)" wrote:
> 
> Hi, Just to add my 2p worth.
> 
> We're running a project which has produced a GSAKMP/LKH implementation for
> use over satellite networks. We have been running the system using a
> satellite link simulator with an error rate of 10-3 and a delay of 0.25s and
> it works great!
> 
> All we did was to have all re-key messages repeated three times, one after
> another.

In the past, we have postulated in MSEC that this simple method would
usually be satisfactory for most IP multicast networks. I'm glad to hear
that your experience that it indeed seems to be the case.

It would be interesting to hear from anyone else who has done real world
testing too.

Thanks,
Brian

> Considering that most modern sat systems say they can give you an error rate
> of approx 10-7 or better, I don't think reliability is much of an issue in
> real world applications. I appreciate it is nice to close the loop, as it
> were, but I think the downside of using up valuable bandwidth and time (in a
> long transmission delay environment) with acks and nacks is hard to justify.
> 
> I would vote on keeping reliability in a separate layer as multicast is
> great for satellite transmission but a constant return path is not always
> available.
>
> regards
> 
> Gavin
> 
> -----Original Message-----
> From: Mark Baugher [mailto:[email-masked]]
> Sent: 27 June 2003 16:14
> To: [email-masked]
> Cc: Brian Weis; [email-masked]; Lakshminath Dondeti;
> [email-masked]
> Subject: [MSEC] Re: [MSEC] Réf. : Re: [MSEC] Réf. : Re: [ MSEC] R éf. :
> [MSEC] [Fwd: I-D ACTION: draft-duquer-fmke- 00.txt]
> 
> Laurence,
>    We discussed putting reliability mechanisms into GDOI about three years
> ago.  The decision of the secure multicast research group (SMuG) at that
> time was to use the mechanisms that are being developed by another group,
> the reliable multicast group, rather than develop our own.  MSEC has also
> taken this approach.
> 
>    So, before we incorporate reliable multicast into an MSEC key management
> protocol, we need to revisit this decision and discuss the pro's and con's
> of having an ACK or NAK mechanism built into key management versus using a
> separate layer.  The advantage that I see of using a separate layer is what
> one generally gets from design modularity:  We can choose among the best
> mechanisms for a particular application.  As new reliable multicast
> protocols and algorithms are developed, these can be used by the key
> management protocol without the need to change the specification of the key
> management protocol.
> 
>    Now, what are the advantages to mixing up reliable multicast with key
> establishment?
> 
>    Finally, I don't see any difference between your Phase 3 and the MSEC
> Rekey protocol (called "groupkey push" in GDOI).  Are there significant
> differences?  I think the similarities in the protocols favor Ran's
> suggestion of including this work with the GDOIv2 effort that MSEC is
> likely to begin.
> 
> Mark
> At 03:56 PM 6/27/2003 +0200, [email-masked] wrote:
> 
> >Hi Brian,
> >
> >Thanks a lot for your very interesting comments. You will find below the
> >answers
> >to your questions.
> >
> >Best regards,
> >
> >Laurence
> >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> >
> >
> > >Hi Laurence,
> >
> > >Thanks for explaining a little more about FMKE. I have some questions
> > >below.
> >
> > >[email-masked] wrote:
> > >>
> > >> Hi,
> > >>
> > >> Thank you for your interest.
> > >>
> > >> FMKE can be seen as an extension of the group key management protocols
> >defined
> > >> in MSEC (and more precisely of GDOI), which aims at providing  an
> > optimized
> > >> scheme for satellite systems. Indeed, satellite based systems have
> > specific
> > >> features which imply specific requirements :
> > >>           - bandwidth limitation, which implies overhead and signaling
> > >> information volume minimization.
> > >>           - High transmission delays
> > >>           - A flat architecture with a high number of satellite
> terminals
> > >> (senders and receivers) (for instance 60000 satellite terminals)
> > >>           - Need for reliable exchanges
> > >>
> > >> Thus, FMKE is designed to limit the number of messages exchanged
> between
> >group
> > >> members and GCKS. For instance the FMKE phase 2 is less resource
> consuming
> >than
> > >> the GDOI ?group key push?, as it requires less messages for an equal
> > number
> >of
> > >> SAs to transmit.
> > >>
> > >> Moreover, on the contrary of the MSEC protocols, FMKE implements
> > reliable key
> > >> distribution exchanges (multicast and unicast). Besides the reliability
> > >> mechanisms are optimized with regards to the bandwidth.
> >
> >
> > >I'm wondering if the Phase 3 messages are distributed along with the
> > >data traffic? For example, if a satellite terminal realizes that it has
> > >missed a Phase 3 message, will it have time to request a retransmission
> > >(by sending a NACK) before it needs to use the keys? If so, do you
> > >expect that it will need to store them until the messages is
> > >retransmitted? I don't know much about satellite terminals, so I was
> > >wondering if they sufficient memory to store a lot of packets.
> >
> >
> >
> >Phase 3 messages are indeed distributed along with the data traffic.
> >In fact, when a new key has to be transmitted, the GCKS has to plan to send
> a
> >phase 3 message containing the key sufficiently early so that several
> >retransmissions can be realised (requested by group members) before group
> >members need the key (for instance before the old key expires). Thanks to
> >these
> >retransmissions, all  satellite  terminals should receive the key in time.
> >
> >
> > >Also, I wonder if the GCKS would be able to handle very large numbers of
> > >NACKs? For example, if there is a wide scale problem and a large group
> > >of satellite terminals discovered that they had missed one or more Phase
> > >3 messages, they'd all send NACKs. If the GCKS has to spend a lot of
> > >time interpreting NACKs, the system won't be very efficient.
> >
> >
> >
> >The GCKS should not handle very large numbers of NACKs. Indeed, when a
> >satellite
> >terminal determines that one message is missing, it waits a pre-determined
> >time
> >before sending its NACK. The waiting time varies for each satellite
> terminal,
> >and follows a pre-calculated distribution, based on link budgets and
> physical
> >satellite terminal location, optimised to avoid massive NACK emission in
> >case of
> >packet loss, and congestion at GCKS side : thus few satellite terminals
> >will be
> >authorised to send a NACK at the beginning, and it is expected that these
> >messages will be sufficient so that all satellite terminals receive the
> GCKS
> >messages. We avoid therefore that all Group members which have not received
> a
> >message send a NACK message.
> >The figure below represents a possible distribution of the waiting time.
> >
> >        | % of group members
> >  100|                                      .     .     .
> >       |                                .
> >       |                                            .
> >       |                     .
> >       |                   .
> >       |                              .
> >       |                           .
> >       |      .    .     .    .
> >     0|________________________________________________
> >                                     waiting time
> >
> >
> >
> >
> >
> >
> > >> Another difference is that in the context of satellite systems,
> satellite
> > >> terminals (= group members) have to protect traffic that they do not
> > generate
> > >> themselves (they are generated by user equipment behind satellite
> > terminals).
> >So
> > >> they know very few information about it. It is therefore more adapted
> that
> >they
> > >> receive directly data SAs from the GCKS for the traffic they have to
> > protect,
> > >> instead of requesting them. In FMKE they receive directly all the SAs
> they
> >are
> > >> authorized to get access to, belonging to one or several groups,
> without
> >having
> > >> to send a request.
> >
> >
> > >The GDOI protocol allows a wide variety of usage models. In the
> > >satellite setting, a GDOI group member can also directly receive data
> > >SAs from the GCKS for the traffic they have to protect. A satellite
> > >terminal would not need to know very much information -- only the
> > >"group" identifier that it sends in the GDOI registration ("Phase 2")
> > >protocol. In a satellite environment, I would expect the group
> > >identifier to represent a set of channels, or some other collection of
> > >services. This is used by the GDOI GCKS to check authorization of the
> > >group member, to ensure that it actually does belong to the group. Once
> > >authorized, the GCKS would return just the KEK for the group. The group
> > >member would then listen for multicasted rekey messages (what you call
> > >"Phase 3" messages) protected by that KEK. When it receives rekey
> > >messages, it then becomes aware of what traffic it needs to protect. In
> > >this manner, I believe that a GDOI group member can also directly
> > >receive data SAs from the GCKS for the traffic they have to protect.
> >
> > >It occurs to me that the GCKS could choose to ignore the group ID if it
> > >has a different method of deciding to which group the satellite terminal
> > >belongs. The GCKS would send the appropriate KEK to the satellite
> > >terminal just as before, and the process would be exactly the same. But
> > >in this way the satellite terminal wouldn't have to know anything at all
> > >beforehand, and the registration messages would be relatively
> > >low-bandwidth messages.
> >
> > >I hope this explanation makes sense. If not, please let me know.
> >
> > >Thanks,
> > >Brian
> >
> >I agree with your explanation. Your scenario indeed implies low bandwidth
> >messages, and as explained in your mail, the knowledge of the Group ID by
> >satellite terminal is no more an issue. In fact FMKE can be seen as a use
> case
> >(and as an extension) of GDOI, particularly for this scenario where FMKE
> >provides similar message exchanges. The only main difference between FMKE
> and
> >GDOI is the reliability of the FMKE Phase 3 ( = the GDOI "Group key push").
> >The scenario where the satellite terminal is entirely configured in unicast
> ,
> >that is to say where it directly receives all Data-SAs and Re-key SA
> >during the
> >FMKE phase 2,  could also be requested for some cases (the phase 3 would
> >then be
> >used only to update the security configurations of the satellite
> terminals).
> >In that case FMKE is more optimized with regards to the bandwidth
> consumption.
> >
> >
> >
> > >> Don't hesitate to contact us if you want further clarification or
> > information
> > >> Best regards,
> > >>
> > >> Laurence Duquerroy
> > >
> >
> > > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > > directories.
> > > >
> > > >
> > > >      Title          : The Flat Multicast Key Exchange protocol
> > > >      Author(s) : L. Duquerroy, S. Josset
> > > >      Filename  : draft-duquer-fmke-00.txt
> > > >      Pages          : 30
> > > >      Date      : 2003-6-17
> > > >
> > > > This document presents a new group key management protocol called
> > > > FMKE (Flat Multicast Key Exchange). Its objective is to manage
> > > > securely group Security Associations (SA), i.e. establish and update
> > > > SAs in Group members. These members can be identified for instance
> > > > by a multicast IP address, a virtual LAN identifier, or a generic
> > > > group label. This protocol is based on a centralized management,
> > > > achieved by the GCKS (Group Controller and Key Server). It is
> > > > destined to be used by Data Security protocols which wish to secure
> > > > group communications. For the time being, the considered Data
> > > > Security protocol is a multicast version of the IPSEC ESP protocol,
> > > > but other Data Security protocols could be envisaged. The FMKE
> > > > protocol exchanges TEKs (Traffic Encryption Keys) and KEKs (Key
> > > > Encryption Keys). The FMKE protocol is optimized for very large
> > > > groups with direct connections such as satellite systems, or wireless
> > > > systems such as WIFI.
> > > >
> > > > A URL for this Internet-Draft is:
> > > > http://www.ietf.org/internet-drafts/draft-duquer-fmke-00.txt
> > > >
> > > > To remove yourself from the IETF Announcement list, send a message to
> > > > ietf-announce-request with the word unsubscribe in the body of the
> > message.
> > > >
> > > > Internet-Drafts are also available by anonymous FTP. Login with the
> > username
> > > > "anonymous" and a password of your e-mail address. After logging in,
> > > > type "cd internet-drafts" and then
> > > >      "get draft-duquer-fmke-00.txt".
> > > >
> > > > A list of Internet-Drafts directories can be found in
> > > > http://www.ietf.org/shadow.html
> > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > >
> > > >
> > > > Internet-Drafts can also be obtained by e-mail.
> > > >
> > > > Send a message to:
> > > >      [email-masked].
> > > > In the body type:
> > > >      "FILE /internet-drafts/draft-duquer-fmke-00.txt".
> > > >
> > > > NOTE:     The mail server at ietf.org can return the document in
> > > >      MIME-encoded form by using the "mpack" utility.  To use this
> > > >      feature, insert the command "ENCODING mime" before the "FILE"
> > > >      command.  To decode the response(s), you will need "munpack" or
> > > >      a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> > > >      exhibit different behavior, especially when dealing with
> > > >      "multipart" MIME messages (i.e. documents which have been split
> > > >      up into multiple messages), so check your local documentation on
> > > >      how to manipulate these messages.
> > > >
> > > >
> > > > Below is the data which will enable a MIME compliant mail reader
> > > > implementation to automatically retrieve the ASCII version of the
> > > > Internet-Draft.
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > msec mailing list
> > > > [email-masked]
> > > > http://www.pairlist.net/mailman/listinfo/msec
> > > >
> > > >
> > > >
> > > >
> > > > ALCATEL SPACE
> > > > RT/ST
> > > > Research Department / Advanced Telecom Satellite Systems
> > > > Tel : 33 (0)5-34-35-63-06  /  Fax : 33 (0)5-34-35-55-60
> > > > E-Mail : [email-masked]
> > >
> > > _______________________________________________
> > > msec mailing list
> > > [email-masked]
> > > http://www.pairlist.net/mailman/listinfo/msec
> > >
> > > ALCATEL SPACE
> > > RT/ST
> > > Research Department / Advanced Telecom Satellite Systems
> > > Tel : 33 (0)5-34-35-63-06  /  Fax : 33 (0)5-34-35-55-60
> > > E-Mail : [email-masked]
> > >
> > > _______________________________________________
> > > msec mailing list
> > > [email-masked]
> > > http://www.pairlist.net/mailman/listinfo/msec
> >
> >--
> >Brian Weis
> >Strategic Cryptographic Development, ITD, Cisco Systems
> >Telephone: +1 408 526 4796
> >Email: [email-masked]
> >
> >
> >
> >ALCATEL SPACE
> >RT/ST
> >Research Department / Advanced Telecom Satellite Systems
> >Tel : 33 (0)5-34-35-63-06  /  Fax : 33 (0)5-34-35-55-60
> >E-Mail : [email-masked]
> >
> >
> >
> >_______________________________________________
> >msec mailing list
> >[email-masked]
> >http://www.pairlist.net/mailman/listinfo/msec
> 
> _______________________________________________
> msec mailing list
> [email-masked]
> http://www.pairlist.net/mailman/listinfo/msec
> 
> This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.

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

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

---

From: Sead Muftic <[email-masked]>
Date: Wed, 02 Jul 2003 10:58:38 -0400

>It would be interesting to hear from anyone else who has done real world

We have done some research on reliability and survivability of a secure
group communication 
system and also some initial real life tests. First, we did not consider
reliability in a sense
of a stable, continuous and reliable multicast communications, but more as
the issues of reliability and
stability of the complete GSA system in a sense of providing continuous
operations to group
members, even in case of unavailability of some GSA components and/or roles.

I have produced a research paper entitled "A Survivable Group Security
Architecture" which I submitted 
to the ACM Workshop (10th Annual ACM Security Conference), so if someone is
interested, please drop me a note.

We have also performed some initial tests with SELinux, running GSAKMP
controller (server) under SELinux,
which provides additional protection of GSAKMP resources and operations.

Regards,

Sead Muftic
CSPRI/GWU