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

[Wassim Haddad <whaddad@tcs.hut.fi>]

On Thu, 7 Sep 2006, Thomas Narten wrote:

> First, what is the intended publication type? informational?

=> the intention is to publish it as 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?)

=> Maybe we should move these two sections to appendix to avoid any
confusion.

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

=> Thank you for raising this point. I agree the title should reflect the
triggering process but also the consequence of such triggering.

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

=> Proxies don't decrement lifetime. In practice, RA information seldom
changes. Usually routers send the same RA again and again.

> 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?

=> OP is an add-on feature to facilitate the interoperability with SeND.
It will be defined in further work.


Regards,

Wassim H.