Subject: [DNA] Route vs Advertise

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

Erik -

It was my understanding that, a host can choose a prefix advertised by
R1 for its address configuration and use R2 as the default router
through which it sends is packets; i.e. advertising a prefix doesn't
mean the router is the only one that can route it.

In SEND, 3971, section 7.3:

Constrained

      If the network operator wants to constrain which routers are
      allowed to route particular subnet prefixes, routers should be
      configured with certificates having subnet prefixes listed in the
      prefix extension.  These routers SHOULD advertise the subnet
      prefixes that they are certified to route, or a subset thereof.

....

   Nodes SHOULD use one of the certified subnet prefixes for stateless
   autoconfiguration.  If none of the advertised subnet prefixes match,
   the host SHOULD use a different advertising router as its default
   router, if one is available.

This text seems to imply that routers advertising a prefix means they
are the ones allowed to route it.
Am I missing something?

thanks,
Sathya

---

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

Hi Sathya,

> are the ones allowed to route it.

I remember this issue from SEND.

Someone else may remember better though.

The issue in SEND is essentially that in some circumstances we want to
guarantee that a router is actually delegated authority to route for
that prefix.   This is in the Certificate, not the PIO.

I'd guess that the origin of the prefix doesn't matter (which RA the
PIO arrives in), although the certificate would indicate that only
those prefixes which are similarly authorized should be used as next
hops for packets with that source address.

Greg

---

From: James Kempf <[email-masked]>
Date: Fri, 03 Jun 2005 06:36:59 -0700

Greg,

That is right, however, this is an optional feature of SEND, because many
ISPs may not have the ability to add the special attributes to the router
certs.

            jak

---

From: Sathya Narayanan <[email-masked]>
Date: Fri, 03 Jun 2005 10:59:30 -0400

Jim -

>That is right, however, this is an optional feature of SEND, 
>
From 3971,

"nodes SHOULD verify that the prefix specified"
and
" Nodes SHOULD use one of the certified subnet prefixes for stateless autoconfiguration"

These conditions are SHOULDs to leave these features optional, is it?

>because many
Can you please point me to the place where these special attributes may
not be added to the certificates?

thanks,
Sathya

---

From: Sathya Narayanan <[email-masked]>
Date: Fri, 03 Jun 2005 11:11:58 -0400

Greg -

Thanks for the response.

Before I go further, I started reading up on SEND to see how DNA should
work with it - the questions I am asking at the moment are for my own
clarifications - but we MAY have to address how the host can verify the
authenticity of the prefixes in a DNAO or even in the Landmark option,
if the certificates tightly bound the prefixes to individual routers.
Please stop me if I am barking up the wrong tree here.

<snip>

> hops for packets with that source address.

Look at the following lines from 3971:

A router MAY, however, advertise a
   combination of certified and uncertified subnet prefixes.
   Uncertified subnet prefixes are treated as unsecured (i.e., processed
   in the same way as unsecured router advertisements sent by non-SEND
   routers).  The processing of unsecured messages is specified in
   Section 8.  Note that SEND nodes that do not attempt to interoperate
   with non-SEND nodes MAY simply discard the unsecured information.

Upon processing a Prefix Information option within a Router
   Advertisement, nodes SHOULD verify that the prefix specified in this
   option falls within the range defined by the certificate, if the
   certificate contains a prefix extension.  Options failing this check
   are treated as containing uncertified subnet prefixes.

Upon receiving PIO in a RA, nodes SHOULD verify that the prefix falls
within the range defined by the certificate - if the check fails, treat
the PIO as unsecure, if a host doesn't want to interoperate with
non-SEND router, it can discard the unsecure PIOs. So, in a all-SEND
nodes world, if hosts do the check on the PIOs - is it fair to conclude
that the routing and advertising of any given prefix will have to be
from the same router(s).

thanks,
Sathya

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 03 Jun 2005 10:44:07 -0700

> hops for packets with that source address.

Is this something which has been implemented in the host SEND 
implementations? I can see it being quite hard since it fits neither the 
BSD-style code, nor the RFC 2461 conceptual model of a host.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 03 Jun 2005 10:44:55 -0700

> mean the router is the only one that can route it.

Your understanding is correct.

Should we move the SEND discussion/clarification to the SEND list until 
we have an answer?

    Erik

---

From: James Kempf <[email-masked]>
Date: Fri, 03 Jun 2005 17:41:44 -0700

> These conditions are SHOULDs to leave these features optional, is it?

Yes.

> not be added to the certificates?

Nothing in the spec, just an observation on the current deployment
situation. For example, if the ISP gets their router cert directly from
Verisign rather than running their own PKI, it might be hard to get the
additional attributes added, and might additionlly constrain network
management flexibility. The IESG requested that we change the MUST to SHOULD
prior to going to RFC for this reason.

                jak

---

From: James Kempf <[email-masked]>
Date: Fri, 03 Jun 2005 17:50:55 -0700

> Please stop me if I am barking up the wrong tree here.

If the certs have prefixes in them, there is no reason why the certs must
only list the prefixes that are currently being advertised. The SEND spec
allows the certs to list a range of prefixes, or even a set of prefixes. So
the range or set could contain all the prefixes on the link, even those not
currently being advertised, indeed, the range could include all the prefixes
in the access network, if the ISP uses a "site" certificate, like many Web
services operators do.

>    with non-SEND nodes MAY simply discard the unsecured information.

Note that this does not imply that the router advertisement should be
considered insecure, just the uncertified prefix. If the advertisement has a
signature verifiable with the router's certified public key, then the router
is trustworthy.

> that the routing and advertising of any given prefix will have to be

That was the intent, a certified prefix means the router is authorized to
route the prefix as advertised.

            jak

---

From: James Kempf <[email-masked]>
Date: Fri, 03 Jun 2005 19:49:52 -0700

Out implementation doesn't work that way. It just uses the prefixes in the
certificate to check whether the prefixes are certified or not, and drops
those that are uncertified if the host is configured to do so. It doesn't
uses the certification to determine what addresses to send to what router
since, as Erik says, that is not in the RFC 2461 conceptual model.

            jak

----- Original Message ----- 
From: "Erik Nordmark" <[email-masked]>
To: <[email-masked]>
Cc: "Sathya Narayanan" <[email-masked]>; "Dna"
<[email-masked]>
Sent: Friday, June 03, 2005 10:44 AM
Subject: Re: [DNA] Route vs Advertise

---

From: Greg Daley <[email-masked]>
Date: Mon, 06 Jun 2005 11:48:44 +1000

Hi James and Erik,

> since, as Erik says, that is not in the RFC 2461 conceptual model.

Thanks for your clarification James.

I wasn't explicitly referring to any particular codebase in my surmise.

Greg

---

From: Sathya Narayanan <[email-masked]>
Date: Mon, 06 Jun 2005 14:42:13 -0400

Jim -

>signature verifiable with the router's certified public key, then the router
I understand.

Do you think we need to say 'the prefixes in the DNAO SHOULD NOT be
verified against the prefixes listed in the certificate' in DNAv6?

- Sathya

---

From: Sathya Narayanan <[email-masked]>
Date: Mon, 06 Jun 2005 14:51:06 -0400

Jim -

>since, as Erik says, that is not in the RFC 2461 conceptual model.
In another email, you say ' That was the intent, a certified prefix
means the router is authorized to route the prefix as advertised.'

So, are you saying your implementation doesn't follow this 'intent'?

Either way, are the 2461 conceptual model and this 'intent' in conflict
with each other?

Sathya

---

From: James Kempf <[email-masked]>
Date: Mon, 06 Jun 2005 12:08:46 -0700

> Either way, are the 2461 conceptual model and this 'intent' in conflict

No, the implementation checks the prefix against the cert (if the cert has
an attribute with prefixes) when the RA is received. That's what I meant by
"router is authorized to route the prefix as advertised". But then the
prefix is put onto the merged prefix list if it passes, as RFC 2461 intends.
The cert is not used to make any routing decisions.

So I don't think the 2461 conceptual model is in conflict.

            jak

---

From: James Kempf <[email-masked]>
Date: Mon, 06 Jun 2005 12:26:03 -0700

> verified against the prefixes listed in the certificate' in DNAv6?

AFIKT, the DNAO is really only useful in multicast RAs. If the RA is
unicast, then the "yes" or "no" bit will be enough to tell the host whether
or not it is on or off link, the host cannot use the DNAO to configure the
address, and it need not use the prefixes in the DNAO to tell whether it is
on or off link because the router does that directly through the "yes/no"
bit. (BTW, why again is the DNAO required in unicast RAs if the host isn't
on link?)

So the host will make its on or off link decision based on the DNAO if it
gets a multicast RA. As long as the RA is covered by a signature, the host
knows that it wasn't modified in transit, that is, that it came from a
router possessing the private key matching the certified public key. Now, it
is possible that the router may be compromised and the attacker may try to
convince the host that it is on or off link when it isn't by sending out a
collection of bogus DNAO prefixes. If we want to exclude this possibility,
then we should require the DNAO prefixes to be compared against those in the
certificate as well. But since the host doesn't use these for address
configuration or routing, there should be no possibility that the host is
convinced to route through a bogus router (though if the router sending the
RA is compromised, it can, of course, make trouble for packets that are
routed through it even if the host selects a certified prefix).

That is a somewhat longwinded way of saying that SHOULD NOT is probably OK.

            jak