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

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

Hi Erik,

Erik Nordmark wrote:
> Greg Daley wrote:
> 
>> Comment:
>>
>> The descriptions here ignore SEND options, which need to be included
>> if SEND is used.  This will increase the size of the RA.
> 
> 
> Probably.
> I haven't looked at exactly what SEND information would be needed in the 
> different cases of an RA being sent.
> If the host didn't move, the RAs will in most cases be sent from routers 
> that the host has previously received RAs from, thus the SEND 
> information can be minimized.
> But when the landmark indicates that the host has moved it makes sense 
> for the RAs to include more SEND information if that makes a SEND host 
> complete the movement faster.
> 
> Is anybody looking at the details of how SEND and DNA can interact 
> efficiently?

Not really, but here's the minimum required (which may violate SEND,
but should be OK in this situation):

For a solicited RA Landmark=yes:

Nonce(8/16), Timestamp(16), RSA Signature (big).

This assumes that the host has seen this Router's RA before, and
has given its trust chain to the host.

If this is insufficient, then CCS/CCA exchange may occur, as well
as NS/NA to get the CGA options...

The host will have to have seen at least one DNA router on the link
though, so it may be possible to wait until another RA from a
trusted router arrives from the same RS.


For a Solicited RA, Landmark=No:

Nonce(8/16), Timestamp (16), CGA Option (big), RSA Signature (big).

Additional exchange of certificate chains may be required in order
to create trust with the router, if the host has never visited it before
(or doesn't remember it).


As far as I can see, to achieve SEND's full replay protection you
can't do any better than this.

>> Question:
>>
>> Can we have standards language for this?
>>
>> There's no flexibility in the description of what options are
>> able to be included in the "Yes" Landmark. That sounds like a
>> MUST NOT include other PIO, DNAO. etc.
> 
> 
> In think the text in section 3 is fine with its use of English, because 
> it tries to introduce the concepts by saying what typically happens.
> But in the core of the draft it makes sense being more specific.

That makes sense.

>> Personally, I'd prefer something saying something like
>>
>> "RAs with the 'Yes' Flag set in a Landmark option MAY leave out all
>> configuration related options such as PIOs, DNAOs, Advertisement
>> Intervals etc, since this information is assumed to have
>> already been received to be able to construct a matching
>> Landmark Router Solicitation".
>>
>> I'd prefer MAY to SHOULD or MUST, since it's an optimization,
>> and the presence of additional options doesn't harm hosts.
> 
> 
> My gut feel is that we should make it a SHOULD NOT, because the host 
> doesn't have any need for this extra stuff, and one of the DNA goals is 
> to be efficient.

OK.

>> In RADVD, it's easier for me to not remove the other options
>> in the RA just because the Landmark option Yes flag is set.
> 
> 
> And the purpose of a SHOULD NOT would be to make you do the work :-), so 
> that we can get an efficient way to do DNA.


That's OK.   My initial work will try to get things going without
the benefits of efficient RA sizing (so long as it's compliant -
which is why I'm asking questions).

Subsequently I'll add an AbbrevAdvertisement option (defaulting to on)
which should cover the Landmark=No and Landmark=Yes cases.

That may take a couple of extra days... :)

Greg