Subject: Réf. : Re: [MSEC] new Internet draft : use caseof GDOI

From: [email-masked]
Date: Wed, 22 Sep 2004 18:31:44 +0200

Hi Mark.

Thanks for all your comments and questions.
Please find below our responses.

Laurence

Mark Baugher <[email-masked]> on 17/09/2004 18:53:54

Pour : Laurence Duquerroy/ALCATEL-SPACE@ALCATEL-SPACE
cc :   [email-masked]
       Sebastien Josset/ALCATEL-SPACE@ALCATEL-SPACE
Objet :     Re: [MSEC] new Internet draft : use case of GDOI

>hi Laurence, Sebastien,
>    I have a few questions and comments.

>1. The first figure shows two cases but there are three:
>star-bidirectional, star-unidirectional, and mesh.  Do I understand
>this correctly?  (It would be helpful to label the figure).

1.Yes, there are 3 cases : star topology with bi-directional communications
between ST and gateway, star topology with unidirectional communications
from gateway to ST, and mesh topology with bi-directional communications
between STs.

>2. I don't understand a sentence on page 5: "Unlike GDOI, this phase
>takes place once, after the Phase 1."  The phase 2, which I think
>you're describing always takes place after phase 1.  After reading this
>paragraph a few times, it seems that you are defining a new phase 2
>pull exchange that allows more than one group to be specified in an ID
>payload so that all groups can be downloaded in one exchange (not
>necessarily in one message because of MTU and fragmentation issues).
>Do I understand this correctly?

2. In GDOI, the "Group key pull" exchange takes place several times, in
fact every time that the group member wants to get access to a new group.
In FMKE, the "philosophy" is different. The group member does not have to
request to get access to a group. It receives directly from the GCKS the
SAs of all groups it belongs to. So we think only one phase 2 per group
member is necessary. This phase is used to transmit to it all SAs it is
authorized to receive (belonging to different groups or not).
Besides, in FMKE, the ID payload is not used. In GDOI, it is used by the
group member to request SAs from a particular group. I think that's the
only utilization (but I could be wrong). So, since in FMKE, the group
member does not request SAs, we have the feeling that it is not necessary
to use this payload. The group member does not need to know that a SA
belongs to one group or another one.

>3. Also on page 5, the innovation introduced to GDOI is to add a
>reliability mechanism to the groupkey-push message is it not?

3.Yes, it is. That's  the only difference for the groupkey-push

>4. On page 6 you discuss the phase 1 but not how the phase 1 is
>established in the star-unidirectional case.  Is this an oversight?  A
>forward reference to 6.1 would help here.

4.OK (it is an oversight)

>5. On page 6, the phase 2 is initiated by the GCKS.  What causes the
>GCKS to initiate this message?  I assume that the first GCKS message is
>sent exactly twice?

5.After much thought, it seems quite difficult to trigger the phase 2 in
the GCKS as it cannot know if the  phase 1 is complete or not.
So, the draft needs to be updated.
The solution which can be proposed is to add a message from the group
member at the begining of the phase 2. This message  would trigger the
phase 2 (like  in the GDOI groupkey pull exchange). We could maybe use the
same message as in GDOI group key pull (with an ID payload set to 0,  in
order not to request the access to a particular group). This solution would
be destined only to bidirectionnal communication cases.

In the case of one-way systems, this message would not be used. The phase 2
would be used as it is described in the current draft, and would be
triggered in the GCKS by a security operator for example.

>6.  How are groups identified in the new phase 2?  I don't see the ID
>payload.

6. See question 2). In the case of FMKE, it seems that groups need only to
be identified in the GCKS, in order that it can identify the group members
and the SAs of each group.

>7. On page 7, the SEQ is redefined to apply to the groupkey-pull and
>not the groupkey-push, if I understand this correctly.  I think it
>would be better not to reuse the name for such a different purpose,
>which I don't yet understand.  Don't we need a SEQ for the original
>purpose of ordering pushed messages?

7.In FMKE, the SEQ payload is used to order GCKS messages:
                  - In a phase 2 , it orders GCKS phase 2 messages (its
function is different from the function of the SEQ payload in GDOI groupkey
pull)
                  - In a phase 3 , it orders GCKS phase 3 messages (same
function as in GDOI).
In GDOI groupkey pull, the SEQ payload is used to mention the sequence
number value of the next groupkey push message sent by the GCKS for the
group identified by the ID payload.
In FMKE, a phase 2 message can contain several Rekey SA, each one
associated to a different group. So it is not possible to mention the next
sequence number value for each group in a payload. This value is mentioned
in the SAK payload as a SA attribute (called Next-sequence-number).

>8. On page 10, it appears that the SEQ is used in the phase 3 so I'm
>confused.  I also don't immediately grasp why the LSEQ is needed since
>the SEQ performs an LSEQ function, or so it seems.

8. The function of the LSEQ payload is to periodically mention the value of
the last sequence number used by the GCKS to order messages containing SAs.
The LSEQ (Last Sequence Number) payload allows group members to detect for
instance that they have not received the last message, and then to request
its retransmission.
Example :
      Next sequence number used by the GCKS  = 5
      Messages sent by the GCKS : 5 6 7 8 9
      Messages received by a member : 5 6 7 . .
      Periodic message with LSEQ value = 9
      Non-acknowledgement   sent   by   the   member   :   Nack  8-9  (this
      non-acknowledgement message triggers the retransmission of messages 8
      and 9)

>9. On page 10 there is also a push message that originates from the
>member.  GDOI reuses the phase 2 for this purpose or a similar purpose.
>  Why not use the GDOI phase 2?

9.I am not sure of understanding the question

>10. On page 13, section 6.1 should be referenced earlier when the
>star-unidirectional topology is described.

10. OK

>11. I'm not sure why the manual configuration of phase 1 SAs cannot
>obviate the need to modify the phase 2 into a push.  In the original
>GDOI design, I thought that the groupkey-push, what you call the phase
>3, would be all that is needed for one-way systems.

11.For one-way systems, using only the group-key push (or phase 3 ) to
configure members is indeed possible. This solution requires to configure
manually every group member with the Re-key SAs of the groups it belong to.
This solution is interesting. However, if new groups are created during the
session, this requires to update manually each corresponding group members.
This cannot be realised dynamically.In satellite systems, STs are distant
from each other and from the gateway, so this is not very easy to realize.
The second solution (i.e.  to use both FMKE phase 2 and phase 3 ) seems
better in this case. Only an initial configuration is necessary. Then any
further configurations can be realized dynamically.Maybe should we keep
both solutions.

Moreover there is another argument for the second solution, but it is out
of the scope of the MSEC group. In fact, it is planed to use FMKE to manage
group SA but also point-to-point SA. Point-to-point SA and Group SA would
be distributed by the GCKS at the same time by using the phase 2 exchange.
That's why we need also to keep the phase 2 in one-way systems.

>12. On page 14, it seems odd to have to modify a pushed message because
>there is no backchannel, since the objective of the push message is to
>operate without a backchannel.  I'm not sure what role the LSEQ plays
>when there is no backchannel:  Why not just send the complete message,
>let the SEQ perform the function of the LSEQ, and send the needed
>payloads in the message?

12. In fact there is a mistake, the messages containing the LSEQ payload
(allowing group members to determine missing messages) are not necessary in
one-way systems, as group members cannot send non-acknowledgement
messages.Besides, push messages sent by the GCKS are not modified for
one-way systems.

>13. Page 15 states that the SEQ is used but does not mention that it
>was redefined as stated earlier in the document.  Also, the list of
>GDOI payloads used is incomplete, isn't it?  What happened to POP?

13.   We have chosen to use the SEQ payload in phase 2 to order the GCKS
messages, because in GDOI, this payload has a similar function in the Group
key push exchange. Maybe it is not the better solution.
For the POP payload, we have considered that it is similar to GDOI, and so
we have not taken the time to describe it in the draft.

>At this point, I am skipping the details of the payloads to ask a
>question:  Would it be possible to modify GDOI as it is without
>developing a new DOI?  I'm sure that there are features missing in GDOI
>for broadcast and for unidirectional networks.  We talked a lot about
>adding reliability mechanisms into GDOI and that's a big topic.  There
>are a number of different reliable multicast algorithms to choose from
>and a "chicken and egg problem" since GDOI is needed to establish keys
>to protect reliable multicast systems.  Speaking strictly for myself, I
>wanted to defer the issue until we had a real system with real experts
>to help.  And here you are.

>My first choice would be to try to minimize the fmke changes and fold
>them into GDOI, publish a new version of GDOI, and cycle on Proposed
>Standard.  The advantage to doing this is that fmke can then benefit
>more directly to bug fixes (such as the POP problem that Catherine and
>her co-author identified), new features (possibly such as sibling SAs),
>and general improvements.  If fmke is incorporated into GDOI, then
>these things don't need to be done twice.

>It might be the case that it's too complicated to try and handle two
>different scenaria in a single protocol, and we'll want to separate
>them.  But 2/3 of your topologies are topologies that GDOI is supposed
>to handle but needs added functionality for reliable multicast.  I
>personally expected that we would need to introduce changes for this.

>Mark

Modifying GDOI in order to fold into it FMKE changes and add supplementary
features could be an interesting option. It is difficult to say now if it
is possible, but we would be very interested to participate to this
analysis .

On Sep 16, 2004, at 12:23 AM, [email-masked] wrote:

> Hello all,
>
> You will find below  the announcement for the new version of an
> internet
> draft whose last version was
> presented  to the group last year, at the Vienna meeting, in July 2003
> (sorry for the long delay!) .
>
> The protocol described in this draft is entitled "Flat Multicast Key
> Exchange". It is destined to be a use case of GDOI adapted for
> satellite
> networks.
> It is defined to be low ressource consuming in bandwidth, to be used
> in any
> satellite networks topologies and to implement a reliable key
> distribution
>
> Taking into account the comments we received , the draft has been
> updated
> in order to present FMKE as a use case of GDOI and to underline the
> differences between both protocols (for the time being , we have not
> changed the name of the protocol, but it could be relevant to do so).
>
> The draft has been submitted to the IETF secretariat as an individual
> draft
> related to no group. We hope that you will find interest in it, and
> that it
> can be officially submitted  as a MSEC draft afterwards.  We thank you
> in
> advance for your comments and questions.
>
> Best regards,
>
> Laurence Duquerroy
> Sebastien Josset
>
> 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]
>
>
> - - - - - - -  - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - -
> - - - -  - - - - - - - - - - - - - - - - - - - - - - - - - - -
> 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-01.txt
>       Pages       : 38
>       Date        : 2004-9-15
>
> This document presents a new group key management protocol called
>    FMKE (Flat Multicast Key Exchange), derived from the Group Domain of
>    Interpretation (GDOI) [RFC3547]. Like the GDOI, its objective is to
>    Manage securely group Security Associations (SA), i.e. establish and
>    update SAs in Group members. These security associations protect one
>    or more key-encrypting keys, traffic-encrypting keys, or data shared
>    by group members. 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 such as the IPSEC ESP
>    protocol. The FMKE protocol is destined to provide an optimized
>    solution for very large groups with direct connections such as in
>    satellite systems, or wireless systems such as WIFI. It can be
>    considered as a GDOI use case adapted for satellite networks.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-duquer-fmke-01.txt
>
>
>
>
>
>
>
> _______________________________________________
> msec mailing list
> [email-masked]
> http://six.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://six.pairlist.net/mailman/listinfo/msec