Subject: Re: WG Last call on draft-ietf-send-psreq-01

From: Greg Daley <[email-masked]>
Date: Mon, 03 Feb 2003 13:57:09 +1100

Sorry about the threading, I've not got a copy of this email,
except on the archives.

James & Pekka,

I'm sure that this is not a very important issue,
but the last paragraph of section 2 has an error
regarding the number of solicited nodes addresses.

The number of solicited nodes addresses as shown by
RFC2373 and draft-ietf-ipngwg-addr-arch-v3-11.txt is
2^24 or 16777216 addresses.

Unfortunately, RFC2461 makes the same mistake as this draft,
and believes there are 2^32 addresses (section 3.1).
I'm pretty sure this is incorrect.

Could this be amended please (the draft, not 2461 ;) ?

Greg Daley

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: "Dave Thaler" <[email-masked]>
Date: Fri, 7 Feb 2003 10:29:58 -0800

I've reviewed the document, and most of my comments relate to
typos/grammar.

Section
1:  The purpose of this document is to define the types of networks the
    Secure IPv6 Neighbor Discovery mechanisms are expected to work,
----- "networks" -> "networks in which"

    number of threats is are discussed in the light of these trust
----- "is are" -> "are"

2:  situation could induce administration hardships when events such as
----- "administration" -> "administrative"

3.1:layer is cryptographically secured to the extend needed, no other
----- "extend" -> "extent"

    a WLAN with 802.11i RNS/EAS may be considered secure enough,
----- don't assume people know what that is.  Expand acronyms and
      add informative reference.  (802.1x could also use an informative
      reference)   Also, in section 3.2 the name appears as "RNS/EAP"
      whereas here it's EAS.  I assume EAS is a typo.

    some or all of the threats outlined in Section 4.  In such case some
----- "In such case" -> "In this case" or "In such a case"

3.2:network, e.g., a WLAN in a hotel, air port, or cafe, has a different
----- "air port" -> "airport"

    under one administrative domain, and the client nodes each fall
under
    its own administrative domain.
----- "its" -> "their" or else
      "the client nodes each fall" -> "each client node falls"

    deployment, the link layer MAY take care of the mutual
    authentication.  The link layer authentication protocol MAY allow
the
----- "MAY" -> "may" in both places (this document isn't the link-layer
      protocol specification)

    Notice that there exists authentication protocols, e.g., variants of
----- "Notice" -> "Note", "exists" -> "exist"

4.1.1
    messages to created bindings between IP addresses and MAC addresses.
----- "created" -> "create"

    (e.g.  CGA) to authorize address bindings.
----- "e.g. " -> "e.g.,"

4.1.2
    The node first waits for a small random delay, and then sends a
----- RFC 2461 does not specify any random delay in NUD.

4.1.3
    This threat involves Neighbor Solicitation/Advertisement.
---- append "messages"?  (same comment in all other sections with
    "This threat involves...")

    sure that no node may allocated more than a few (hundreds of)
----- "may" -> "has".  However, I think this suggestion should be
removed,
      as there may be situations where allocating a large number is
      desirable (e.g. creating a separate address per TCP connection,
      or when running an ND proxy).  In my opinion, the WG should not
      suggest that ISPs bound how many addresses a legitimate host can 
      have.

4.2.4
    rebooting, or the same prefix is advertised with a zero lifetime.
----- "or the" -> "or after the"

    This attack can be extended into a redirect attack if the tacker
----- "tacker" -> "attacker"

4.2.5
    DNS based on the bogus constructed address.  DNS update causes the
----- add informative reference for DNS update

    other IP address in the AAAA RRset, which may be correct.
----- "address in the AAAA RRset" -> "addresses registered in DNS".
      (omitting AAAA since it could fall back to IPv4 addresses too)

    There is also a related possibility of advertising the a target
----- "the a" -> "a"

4.2.7?
----- another pure ND threat is that a node may spoof messages that
cause a
      reply (e.g., echo requests), sending them unicast to a target
      node.  This results in a DoS attack on the target's neighbor
      cache just like in 4.3.1 but here the target is a host rather than
a
      router.  This is sort of mentioned at the in 4.3.1, but it should
      really have its own subsection under 4.2.

4.3.1
     problem.  Rate limitating Neighbor Solicitations, restricting the
------ "limitating" -> "limiting"

4.4  new address via DynDNS is not considered an ND security issue
------ be consistent.  Here the term DynDNS is used where as in 4.2.5
       it was DNS update.

6    identifying the Neighbor Discovery DOS attack.  We would also like
to
------ "DOS" -> "DoS"

     Thanks to Alper Yegin of DoCoMo Communications Laboratories USA for
...
     Thanks to Alper E.  Yegin, Pekka Savola and Bill Sommerfeld for
their
------ be consistent with Alper's name

-Dave