Pasi Eronen: 

o  Section 9 says that "Unsolicited Neighbor and Router Advertisements 
   sent by a SEND router MUST be secured.". I guess the text about
   unsolicited NAs applies also to non-router SEND nodes?

o  Section 11.2.1: Should this section also mention the case when
   cache entries are created as a side effect of non-DAD Neighbor
   Solicitation, or when cache entries are updated as a result of
   unsolicited Neighbor Advertisement? (BTW, I have a feeling that
   some parts of the document don't take unsolicited NAs into account)

-------

Jari Arkko:

> Section 9 says that "Unsolicited Neighbor and Router Advertisements 
> sent by a SEND router MUST be secured.". I guess the text about
> unsolicited NAs applies also to non-router SEND nodes?

Section 9 text has now been clarified & simplified. It now reads
as follows:

   In a mixed environment SEND nodes follow the protocols defined in
   RFC 2461 and RFC 2462 with the following exceptions:

      All solicitations sent by SEND nodes MUST be secured.

      Unsolicited advertisements sent by a SEND node MUST be secured.

      A SEND node MUST send a secured advertisement in response to a
      secured solicitation.  Advertisements sent in response to an
      insecure solicitation MUST be secured as well, but MUST NOT
      contain the Nonce option.

      ...

> Section 11.2.1: Should this section also mention the case when
> cache entries are created as a side effect of non-DAD Neighbor
> Solicitation, or when cache entries are updated as a result of
> unsolicited Neighbor Advertisement?

It should! In addition I have shortened the text and removed the
subsections. Here's the updated version:

   This threat is defined in Section 4.1.1 of [27].  The threat is that
   a spoofed message may cause a false entry in a node's Neighbor Cache.
   There are two cases:

   1.  Entries made as a side effect of a Neighbor Solicitation or
       Router Solicitation.  A router receiving a Router Solicitation
       with a firm IPv6 source address and a Target Link-Layer Address
       extension inserts an entry for the IPv6 address into its Neighbor
       Cache.  Also, a node performing Duplicate Address Detection (DAD)
       that receives a Neighbor Solicitation for the same address
       regards the situation as a collision and ceases to solicit for
       the address.

       In either case, SEND counters these treats by requiring the
       Signature and CGA options to be present in such solicitations.

       As discussed in Section 8.1, SEND nodes preferably send Router
       Solicitations with a CGA source address, which the router can
       verify, so the Neighbor Cache binding is correct.  If a SEND node
       must send a Router Solicitation with the unspecified address, the
       router will not update its Neighbor Cache, as per RFC 2461.

   2.  Entries made as a result of a Neighbor Advertisement message.
       SEND counters this threat by requiring the Signature and CGA
       options to be present in these advertisements.

   See also Section 11.2.5, below, for discussion about replay
   protection and timestamps.

In addition, the normative part of the document appears incorrect,
as the CGA option is not required for solicitations that might
have an effect. This has now been corrected, Section 7:

      All Neighbor Solicitation messages sent MUST contain the Nonce,
      Timestamp, CGA, and Signature options.  The Signature option MUST
      be constructed with the sender's key pair, using the configured
      authorization method(s), and if applicable, using the trust anchor
      and/or minSec value as configured.

And Section 8:

      Router Solicitation messages sent with an unspecified source
      address MUST have the Nonce and Timestamp options.

      Other Router Solicitations MUST have the Nonce, Timestamp, CGA,
      and Signature options.  The Signature option MUST be configured
      with the sender's key pair, setting the authorization method and
      additional information as is configured.

> (BTW, I have a feeling that some parts of the document don't
> take unsolicited NAs into account)

I went through the document but could not find anything alarming
about this. You do not have a specific part of the document in
mind?

-------

-------

-------