Subject: [MSEC] three questions on GDOI...

From: Luca Venturi <[email-masked]>
Date: Fri, 10 May 2002 15:37:48 +0200

Hi everybody,

I am a student who is trying to simulate gdoi on 'ns' for my graduation
thesis work. Howevere there are some points about gdoi I can't figure
out from the draft, and I hope someone from the mailing list can help
me:

1) What must happen when a group member notices that it has lost one ore
more 'PUSH' messages, e.g. it doesn't know the actual TEK and it notices
that thatit is no more able to decrypt the incoming data traffic and/or
that it has not the actual KEK to decrypt the TEK? Does it have tu
re-run the entire 'PULL' Protocol, or is eventually a single notify
message from the member to the GCKS enough?

2) What must happen when a group member decides to leave the group? How
does it have to notify its decision to the GCKS?

3) Finally, can you suggest a network topology scenario that might be
meaningful for my simulation? 

Thank you so much in advance for your help

Luca Venturi

---

From: Brian Weis <[email-masked]>
Date: Tue, 14 May 2002 18:58:03 -0700

Hi Luca,

> message from the member to the GCKS enough?

If the group member receives PUSH messages for the group and finds that
he does not have the current keys, then he must do a PULL protocol in
order to get the most recent keys.

> does it have to notify its decision to the GCKS?

We haven't provided a mechanism for a group member to announce his
leaving. The only time a GCKS would care is if he's keeping an LKH tree,
since only then does he keep state for each group member. In that case a
new notify message type might be useful to the GCKS so he can prune his
key tree. However, the GCKS can't depend on a group member telling him
that he's leaving -- the client might crash or just shut down without
notifying the GCKS. The GCKS needs a more reliable mechanism for knowing
when group members have left the group.

> meaningful for my simulation?

The following draft describes a couple of topologies:
	http://www.securemulticast.org/draft-irtf-smug-taxonomy-01.txt
You might find other helpful information on www.securemulticast.org as
well.

Good luck,
Brian

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