Subject: ZMAAP Comments

From: Steve Hanna <[email-masked]>
Date: Tue, 14 Aug 2001 17:26:00 -0400

All,

Here are some comments on draft-ietf-zeroconf-zmaap-01.txt.

Thanks,

Steve Hanna

-----

Comments of some substance:

1) One concern about the "shared defense" feature, which
I mentioned to Erik last week. 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).

2) 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.

3) It would be nice to have a range of multicast addresses
allocated by ZMAAP that would be restricted to never leave
the zeroconf network. Why not ask the IANA to reserve such
a range?

4) I suggest adding a magic number (0x83627365, or some such)
to the start of each ZMAAP packet, so that it's easy to detect
and ignore non-ZMAAP packets.

At the zeroconf working group meeting at IETF 51, I suggested
this and was told "that's what the UDP port is for." In a
sense, that person is right. But users are often allowed to
casually override the UDP port used by a particular program
(as with URLs like http://sun.com:8080). The magic number
would provide a more robust mechanism to detect bad
traffic.

In my opinion, all multicast protocols should employ a magic
number to detect multicast address allocation conflicts. In
fact, multicast protocols that support multiple sessions
on separate multicast addresses (which will usually have
different receiver sets) should include a short session
identifier in all (or most) packets so that they can detect
multicast address conflicts.

I don't feel strongly about this, however.

5) Section 4.4.4 says that if a received AIU includes
a range that overlaps with an entry in the allocation
record but the lease descriptors don't match, an allocation
conflict exists and the entry must be removed from
the allocation record. But what if the only difference is
the lease lifetime? That should be OK, especially if the
entry in question is a "shared defense" allocation.

For a shared defense allocation, you should probably just
update the time to match what you saw in the AIU. That may
be troubling if this results in a shorter lifetime than you
wish you had, but it allows the original allocator (or
anyone else, since we don't have any authentication) to
change the lifetime to extend or shorten it. Also, clocks
aren't synchronized and network transmission delays are
non-zero, so lifetimes expressed as remaining seconds
(as is done in ZMAAP) will almost never match.

6) 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.

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.

Editorial Comments

1) The fourth paragraph of section 4.1 talks about how an
application can ask a local mini-MAAS to defend an address
that was originally allocated by another mini-MAAS
("shared defense"). There is a parenthetical remark about
an API being useful here. This is a complicated topic.
I suggest that you omit the comment about the API and
instead refer the reader to a more extensive discussion of
shared defense later in the spec.

2) I suggest that you split the discussion of shared defense
out of section 4.4.2 into a section of its own and expand
the discussion of shared defense to describe more completely
how this can be done. You should point to a session
advertisement protocol (or service location protocol or
directory protocol) and describe how this protocol can
be used to convey the Lease Identifier and Lifetime (as
well as the address range), perhaps by referring to Appendix B.
This will narrow section 4.4.2 to the more common case of
defending one's own allocation.

I also suggest moving the description of how to handle an
ACLM with the same Lease Identifier as one of your own
allocations to the end of section 4.4.2. This is not the
most common case.

3) The last sentence of the third paragraph of section 4.1 is
missing a subject and generally needs a bit of work. How
about this: "If, on the other hand, the mini-MAAS receives
no AIU response when the allotted time expires, it assumes
it has succeeded in allocating the range of addresses."

4) The first sentence of section 4.2 does not seem very useful.
The preceding section provided a much better description of
who sends AIUs and when. I suggest that it be removed.

5) I suggest splitting the fourth paragraph of section 4.2 in
two. Append the first two sentences to the previous paragraph.
They are simply a continuation of the description of the
destination address of ZMAAP packets. Let the third sentence
stand on its own. It's a separate matter, a requirement on
mini-MAAS's. But fix the typo in that third sentence: "is"
should be "it".

6) Section 4.2 includes a list of scopes for which ZMAAP
may be used. Item (3), IPv6 Dynamic Subnet-Local is not
described in RFC 2373, as indicated by the reference.

7) In section 4.3, the description of the Lease Lifetime is
missing the word "for" between "seconds" and "which".

8) In section 4.4, you might want to define a term to mean
the complete set of allocations known by a mini-MAAS for
a given scope (instead of going out of your way to *not*
define a term for it). I suggest the term "extended
allocation record". For a MAAS that does not retain a
record of allocations other than its own, this will be
identical to the allocation record.

Then you can use that handy-dandy term you've defined in
the second paragraph of section 4.4.1, where the mini-MAAS
should consult its "extended allocation record" when
selecting free addresses.

Also, you might want to mention that the "allocation
record" includes "shared defense" allocations, as well.

9) The last paragraph of section 4.4.3 should spell out
all the steps involved in verifying a lease identifier:
send ACLM messages; if you get back an AIU with the expected
lease information, fine; otherwise (no AIU or none that
matches), verification fails.

10) Section 4.4.5 says that you can prolong a lease by
sending an AIU, but it doesn't say quite how. I assume
(as noted in "comment of some substance" 5 above) that
this is done by increasing the lifetime and leaving all
the other parameters (Lease Identifier and addresses)
the same. You should say this explicitly.

Note that this can also be used to shorten the lifetime
of an address. The text seems to indicate this is a bad
thing. In most cases, it's not needed. But I wouldn't
say it's bad. If you have a long lease on an address from
a tight address space and you don't need it any more,
I think it would be best to send an AIU with a short
lifetime.

11) Several values defined in section 5 don't seem to be
used anywhere: REPEAT-INTERVAL and DETECT-INTERVAL. Did
you mean to refer to them elsewhere? If not, you should
remove them. The world is complicated enough already.