This paper describes the current state of IETF specs related to
multicast security and key management.  It then proposes using new HIP
service for multicast group controller/key server.  The claimed
benefit benefit of this idea is that it avoids unnecessary rekeying
when a member node is mobile.

Technical
---------
Sections 5 and 6
- If I understood correctly
  In Section 5 you identify two problems
  a) source address spoofing is a problem if member authentication for
     key maangement is based on shared keys
  b) unnecessary key updates may be done if a multicast member is
     mobile
  In Section 6 you then propose HIP registration service as a solution
  to both problems.

  What does "key management is based on shared keys" mean?
  Intuitively one would think that it means each member shares a
  _separate_ key with the GCKS.  If so, sender authentication in SSM
  should not be a problem if something like TESLA is used.  I see that
  sender authentication is a problem if even key management is based
  on a common shared key.  But is anyone seriously proposing that?

  Second, what is the identifier used by GCKS for authenticating the
  members?  If it is not an IP address but something else, then does
  IP mobility imply key updates?  If it is IP addresses, is that
  reasonable? 

Editorial
---------
Section 1.2
- last two paragraphs of page 1 column 2 seem to say the same thing
  repetitively
- Section 3.1, page 3 last line: Table 1 does not say anything about
  the number of key update messages needed when the tree structure is
  NOT being used.
- Section 3.2.2
  - empty reference to IKE
  - "peer-to-peer" should be "point-to-point"
  - "HASHes include nonce values": I guess at least HASH(1) does not
     include Nr
- the biggest editorial issue is that the paper assumes a reader who
  is familiar with ISAKMP notation and IETF terminology.
  especially Figure 5