Subject: changes for zmaap-02

From: Erik Guttman <[email-masked]>
Date: Thu, 30 Aug 2001 15:48:59 +0200 (MET DST)

I plan to make the following changes to ZMAAP based on feedback
at IETF 51 and from Steve Hanna.  

I will respond to editorial issues directly, and not include
them in the 'revision list.'

In responses, please include the revision # to ease tracking.

--------------------------------------------------------------------

rev-zmaap01-01  Shared defense will lead to implosions

  Issue:

  If a lot of mini-MAAS's decide
  to perform secondary defense for a particular allocation, they
  may mount an involuntary Denial of Service attack by responding
  to a single ACLM with one AIU from each defender. I suggest
  having secondary defenders set a timer to a randomized
  value with an exponential distribution weighted toward
  the long side and only send an AIU if they don't see any
  other AIUs before their timer expires (like SAP).             

  Suggestion: 

  Add timer, listening and only if no other defender AIU sent,
  send shared defense AIU message.

rev-zmaap01-02  Full address space could cause thrashing

  Issue:

  When the multicast address space is full or almost full,
  a new mini-MAAS may require many ACLMs to find a free
  address (or determine that there aren't any). We might want
  to suggest a minimum interval to wait before making a new
  allocation attempt (100 ms?). We should also recommend some
  limit on this retry mechanism: a maximum number of retries,
  probably.

  Suggestion:

  Add retry wait text and max # retries (say no more than 
  50% of the address space?)

rev-zmaap01-03  Reserve IPv4 LINKLOCAL address range for ZMAAP

  Issue:

  We need a range for ZMAAP.  

  Suggestion:

  Request it from IANA.
  
rev-zmaap02-04  Reserve IPv4 ZEROCONF multicast scope 

  Issue:

  This is a multicast range coextensive with the zeroconf network
  extending across all routers internal to it.

  Suggestion:

  Request such a range from IANA.  Will we need a specification
  for this multicast address space to justify it?  Does anyone
  believe that this scope is a good idea?  (I do).  What would
  the corresponding IPv6 scope be?

rev-zmaap01-05  Magic # in ZMAAP header to prevent conflicts

  Issue: 

  Since multicast protocols SHOULD detect and gracefully deal 
  with protocol conflicts of use on their port #s, we could add 
  a magic number preamble to the header.

  Suggestion:

  Add 2 bytes of magic # as a preamble to the header.

rev-zmaap01-06  Clarify matching Lease Descriptors

  Issue:

  Do leases conflict if they have an overlapping instead
  of identical range and the same Id?

  Do leases conflict if they have the same address range
  and ID but different lifetimes?

  What should be done in these cases?

  Suggestion:

  Nonmatching ranges indicate a conflict even if the ID matches.

  Matching ranges and IDs are not a conflict.  Use the latest
  lifetime seen, as Steve Hanna suggests.

rev-zmaap01-07  WEP language in security considerations section

  Issue:
  In light of the latest attacks on WEP, the last
  few sentences of the Security Considerations section are
  no longer true. WEP does not provide "privacy equivalent 
  to a wired network". By monitoring 802.11 transmissions
  for a short period of time, anyone can discover the key
  in use, effectively nullifying any benefits of WEP.

  Suggestion:

  I suggest that we replace the last three sentences of
  the Security Considerations section with this:

    The "Wired Equivalent Privacy" (WEP) protocol [9] was
    intended to provide privacy equivalent to a wired
    network, but it has been shown in several recent papers
    [19] [20] to have fatal flaws. Therefore, the use of
    ZMAAP over wireless networks is NOT RECOMMENDED at
    this time.

  [19] Fluhrer, S., Mantin, I., and A. Shamir, "Weaknesses
       in the key scheduling algorithm of RC4", Eighth
       Annual Workshop on Selected Areas in Cryptography
       (August 2001).

  [20] Stubblefield, A., Ioannidis, J., and A. Rubin,
       "Using the Fluhrer, Mantin, and Shamir Attack to
       Break WEP", http://www.cs.rice.edu/~astubble/wep.

  If we don't make this change, I expect that the IESG will
  make it (or something similar) for us. If we aren't
  comfortable saying that ZMAAP shouldn't be used over
  wireless networks (I know I am), we should probably design
  some security to be used with it.

rev-zmaap02-08  Do not add periodic advertisements

  Issue:  

  In order to detect conflicts in a timely way, either
  polling or periodic adverts are needed.

  But, conflicts are not fatal (multicast apps have to be
  robust to them on the same port, and if on different ports
  this will only result in non-optimal filtering of multicast
  packets - at IP layer rather than by hardware).  Periodic
  signalling is expensive and to be avoided.

  Suggestion:

  Add in an API for applications to tell the ZMAAP implementation
  when they have discovered a conflict.

  Tolerate conflicts - that is, the NOTIFY apis will be on a best
  effort basis, and likely not work at all.

rev-zmaap01-09  Add session discovery & announcement to ZMAAP

  Issue:

  Apps need to know whether to join an existing session or to
  allocate a new one.  This could be a race condition.

  After a conflict, apps need to know which session to move to
  as the above race condition will likely result.

  Suggestion:

  Session Description Protocol, RFC 2327, defines 
    s=<session name>
    o=<creator/owner and session identifier>

  Use this very abbreviated portion of SDP *in place of lease
  ids* as specified by ZMAAP currently.

  In AIU messages this will announce the allocation 
  associated with a session.

  In ACLM messages this will ensure that session allocations
  will not conflict.

  Session discovery?

  Add a new message SQUERY.  It includes the SDP info listed
  above.

  Add a new message SREPLY.  It includes the lease descriptor
  and the complete SDP associated with the session.  Mini-MAASs
  MUST passively receive interpret SREPLY to detect conflicts.

  The reason for 2 additional messages is that its better not
  to overload ACLM for session querying and it is desirable
  to get the entire SDP in a reply, which is inappropriate for
  the AIU reply, which may include many lease descriptors - 
  in the case of a range of addresses in an ACLM which conflicts
  with more than one allocation.

--------------------------------------------------------------------

Erik