Subject: issue 44 - host to check its own address against router cert prefixes?

From: Jari Arkko <[email-masked]>
Date: Sat, 20 Dec 2003 12:17:20 +0200

Jonathan Trostle wrote:

> Jonathan Trostle: (2) there's no mention of whether the host checks
> that its IP address is contained in the prefixes or ranges in the
> router's certificate.  Suggestion: if not, the host MUST either find a
> new router or obtain a new IP address and recheck.  (An IP address
> might be obtained using DHCP as well).

And James Kempf wrote:

> James Kempf: I think there's an implicit assumption that CGAs are
> being used with secure RAs, which might not necessarily be the case,
> so there probably should be some text in the spec about this.

First I'd like to understand this issue better. I think
you are not talking about the router's own address -- because
the router's address is either (a) link local or (b) given
through the R flag and automatically within an advertised prefix.
So I think we can agree that it is not possible for routers
to give wrong addresses, as long as their RAs are valid.

Secondly, we have the issue of the host's own addresses.
I don't this is a matter of just checking if we have the
right type of address already. When we receive the RA, we
are building the default router list as well as a list of
prefixes for the link. If this is the first time we hear
from this router, it is possible that we have not heard
from the prefixes yet either. So in this case we would need
to adopt the router as least as far as prefixes and address
autoconfiguration goes. When DAD completes later, at that
point the host may for the first time have an address that
is in the range of the router's certificates.

I do not think we need to do anything special to cause
address autoconfiguration to be performed for new prefixes,
standard ND already takes care of that.

But the question is perhaps what to do in terms of routing.
As far as I know -- but I could easily have missed something -
RFC 2461 does not restrict the use of a default router for
just traffic that uses this router's prefixes. There is also
no rule that says we can only use a default router only if
we have succeeded in defining an address for one of the
prefixes advertised by the router.

Is there a need to change this for SEND? I'm not sure I
see a need for a host to define an address P::IID just
because it wants to send something from Q::IID over a
router that only advertises P. There is no connection
between P and Q, so I'm not sure what this would help.

However, is there a need to restrict all traffic out
from the router to use just those prefixes that the
router advertised and is authorized to advertise?
If we did this, it would provide automatic ingress
filtering... but perhaps it would be too limiting.

If we do not do this, a legitimate router could
appear in other links, and fool hosts to use itself
as a default router, even for traffic which uses
prefixes that the router is not authorized to
advertise.

I guess the question is what the certificates actually
authorize the router to do: to advertise prefixes,
or to route traffic? Our own document seems confused
on this point. Extract from Section 6.1.1:

    The X.509 IP address extension MUST contain at least one
    addressesOrRanges element that contains an addressPrefix element with
    an IPv6 address prefix for a prefix the router or the intermediate
    entity is authorized to advertise.  If the entity is allowed to route
    any prefix, the used IPv6 address prefix is the null prefix, 0/0.

We have the following alternatives:

(1) Define the IP addresses as *advertisement* rights. No checks
     for using a default router.
(2) Define the IP addresses as *routing* rights. Then routers
     might actually advertise less prefixes than they are authorized
     to route. A check would be needed to prevent hosts from using
     a default router for packets that have a source address not
     belonging to the authorized set.
(3) Do (1) now and work on (2) later.

I think option (2) sounds the right one. What do others think?
Are there any issues in the host routing check that this would
imply? Note that it would be at least conceptually a per-packet
check.

--Jari

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: "James Kempf" <[email-masked]>
Date: Mon, 22 Dec 2003 09:49:30 -0800

I agree with option 2 but I don't think we need to specify how to do ingress
filtering in the document, though it might be worthwhile to reference a
document where it is described. A reference might be hard to track down,
though, since it is such a commonly known security technique.

            jak

----- Original Message ----- 
From: "Jari Arkko" <[email-masked]>
To: "SEND WG" <[email-masked]>; "James Kempf"
<[email-masked]>; "Pekka Nikander" <[email-masked]>
Sent: Saturday, December 20, 2003 2:17 AM
Subject: issue 44 - host to check its own address against router cert
prefixes?