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

From: Greg Daley <[email-masked]>
Date: Wed, 01 Jun 2005 14:52:13 +1000

Dear WG,

The contents of Landmark RAs with the Yes flag set
are described in two locations:

Section 3.2:

"In the case when the host is still attached to the same link, which
  might occur when the host has changed from using one layer 2 access
  point to another, but the access points are on the same link, the
  Router Advertisement(s) it receives will contain a "yes, that prefix
  is on this link" answer, and no other information.  Thus, such RA
  messages are quite small."

Section 5.1.5:

"If the RS contains a Landmark Option whose prefix matches one
  of those in the interface's stored prefix list, then the
  Landmark option with the Landmark prefix is included in the RA
  but with the Yes flag set.  At this point the RA is ready for
  transmission, and is scheduled as specified in Section 5.1.7."

I have a comment and question.

Comment:

The descriptions here ignore SEND options, which need to be included
if SEND is used.  This will increase the size of the RA.

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.

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.

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.

Greg

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 01 Jun 2005 10:59:16 -0700

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

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

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

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

    Erik

---

From: Greg Daley <[email-masked]>
Date: Thu, 02 Jun 2005 11:34:28 +1000

Hi Erik,

> Is anybody looking at the details of how SEND and DNA can interact 

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.

> But in the core of the draft it makes sense being more specific.

That makes sense.

> doesn't have any need for this extra stuff, and one of the DNA goals is 

OK.

> 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

---

From: Sathya Narayanan <[email-masked]>
Date: Thu, 02 Jun 2005 13:23:48 -0400

Greg -

> <snip>

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

> 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

>> 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.
>> doesn't have any need for this extra stuff, and one of the DNA goals
>> is to be efficient.
>
>
> OK.
>
>> 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.
>
>
>

---

From: Greg Daley <[email-masked]>
Date: Fri, 03 Jun 2005 12:24:39 +1000

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

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