Re: [DNA] leaving out options on Landmark RA =Yes(draft-pentland-dna-protocol-00.txt)?

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Sathya.

Sathya Narayanan wrote:
[cut]
> Why do you say 'may violate SEND'? It looks correct to me.

Perhaps it is,  I was working on the principle that a solicited
RA needs to have a CGA option...

I'd need to check again to see if that's the case (I think it's
actually a MAY include the option).

[cut]
> Why do you include the CGA option for 'No' answer - SEND doesn't require
> CGA option in the RA messages, unless the interface is configured to use
> CGA? Is that correct? 


Well, SEND doesn't yet provide a way (other than explicit certificates)
to authenticate the origin and content of messages except through
using CGA.

The CGA option provides not only the static parameters for the CGA,
but also the Public key of the CGA sender.

So it's not required to be sent, but it is required to be known,
if we want to believe that the message is unmodified from the sender.

> If that is the case, the CGA option should be
> present for both 'Yes' and 'No' answers - unless the CGA option is
> needed only for the first time? Is that so? I couldn't find anything in
> 3971 that suggests that CGA option is needed only for the first time.
> Please explain.

The content in the CGA option but should be cached
from the first RA (or NS or NA) reception.  So it's not
needed in every message.

It's typically not required in an unsolicited RA for
example (in fact it is a MAY for reception in RAs).

Rules are detailed in 5.1.1.  (Processing Rules for Senders)

For the landmark=NO case, we want to verify  (at least
the message integrity) without additional transmissions.
This requires passing the public key and CGA parameters in the
same message as the responding RA.

Otherwise, the message is unverifiable without external
message exchanges.

So CGA Option in a landmark=NO is important if we want
message origin integrity because we're assuming the host
hasn't been on the link before.

For Landmark=YES, we make the opposite assumption. Therefore,
we can leave out the CGA Option.

There's a chance that a responding RA is from
a router which hasn't been seen, or is no longer cached.
I guess this is the same assumption made in unicast NS
which doesn't mandate SLLAO though.

In general I think you're right.  CGA option wouldn't
be needed.

I think it's pretty important if we're assuming the option
isn't in the cache.

Greg