Re: [DNA] WGLC for draft-ietf-dna-frd-02.txt

[Thomas Narten <narten@us.ibm.com>]

Some quick comments.

Note that this is not a detailed review. I think there are some bigger
issues to discuss first before I'm willing to do a detailed review.

First, what is the intended publication type? informational? (Hmm,
later I see it has what seems like a protocol change regarding
Ownership Proof. That would seem to imply standards track. What is
it?)

Second, the document title is misleading. Rather than calling this
"fast router discovery", I think it should be called something like
"triggered router discovery", since the whole point is to have the
sending of RAs triggered by a link up type event.

One issue with RA proxying is that the info in a cached RA may be old
and invalid. RAs include lifetimes in units relative to "now". Caching
an RA for (say) 15 minutes means that the lifetime information in that
RA is now potentially very incorrect. Are proxies supposed to muck
with lifetimes and decrement them in real time? Note that this would
presumably break SEND (and any other way of securing RAs). I don't see
discussion of this anywhere.

The security considerations talks about some of this, but includes:

   We may resolve this issue by including a unique 64 bit number called
   an Ownership Proof (OP) in an RA.  The 64 bit number, OP, is the hash
   of a nonce and proves to a host that the RA was indeed generated by
   the router which is listed as the source of the RA.  The router must
   keep a table associating each OP to the nonce, which was used to
   generate it.  When an RA carrying an OP option is received, a host
   may ignore the SEND Timestamp option if it falls outside the
   allowable window.

is this a required part of the spec? Where is the OP field defined?

Reading through the algorithms, I'm pretty dubious of this, plus its
way out of scope for this WG to be defining such changes.

Some of the references need updating and or an evaluation of whether
they are really normative. For example:

>    [4]   Kempf, J., "Detecting Network Attachment in IPv6 Networks
>          (DNAv6)", draft-ietf-dna-protocol-01 (work in progress),
>          June 2006.

is listed as a normative reference. Given that this document can't be
published until all normative references are also ready, I wonder if
we should be advancing this document at this time. Seems like we
should wait until the merged document is done before advancing other
documents that depend on it.

Section 5.1.2 scanning, says:

   First it scans the L2 frame header to see whether it is a multicast
   frame.  If not, the PoA sends that frame down link and scans the next
   L2 frame.  If so, the PoA looks IP header to check whether it
   contains a suitable RA.  If an incoming L2 frame doesn't contain a
   suitable RA, the PoA sends that frame down link and scans a next L2
   frame.  When the PoA finds a suitable RA, it stores it and sends a
   copy down link.

The above seems incorrect, since RAs can be unicast. Yet, we only scan
for multicast ones?

   A PoA can scan continuously, updating an old RA with a new RA.
   Alternatively, if it costs too much for the PoA to scan every
   incoming L2 frame, we can control the scanning rate.  For example, we
   can set timer and execute scanning every T seconds.

This strikes me as bizarre/broken and can easily lead to the caching
of old information. We shouldn't recommend something like this.

Thomas