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

[Sathya Narayanan <sathya@research.panasonic.com>]

Greg -

> <snip>
>
>>
>> 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):

Why do you say 'may violate SEND'? It looks correct to me.

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

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

thanks,
Sathya


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