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

From: "James Kempf" <[email-masked]>
Date: Mon, 5 Jan 2004 10:45:56 -0800

Jari/Greg/Mohan,

Interesting conversation.

> > Router selection depends on many factors, including
> >
> >  - Router Information (RI) options for the destination address
> >    (draft-ietf-ipv6-router-selection-02.txt)
> >  - Prf field in the RA (same draft)
> >  - Router lifetime value as per RFC 2461.
> >  - Trustworthiness of the given router, handled by the usual SEND
> >    mechanisms.
> >  - Routing rights/expected ingress filtering behaviour, which is
> > where    this discussion started.
> >
> > The first three factors exist even in non-SEND hosts. Router lifetime
> > has higher priority than the RI option or Prf values, i.e., a router
> > with a zero lifetime does not get selected as a default router for
> > anything regardless of any attractive RI options it might have.  And
> > specific information carried in RI, I think, has higher priority than
> > the default router priority Prf.
> >
> > General trustworthiness of a router is an on/off kind of thing,
> > similar to the router lifetime zero check. This means that it has
> > higher priority than the other checks; a bad router will not be
> > selected for anything.
> >
> > The interesting part is the routing rights issue. This is in fact the
> > same thing as the expected ingress filtering; one of the questions we
> > are debating is what kind of ingress filtering we should expect from
> > routers when there are at present no explicit protocol means to
> > determine this.
> >
> > I think James argued convincingly that the certs have routing rights
> > information. The remaining questions are:
> >
> > (1) Are the routing rights same for all routers on the link?
> >
> >    If they are not, then there is a need to change default router
> >    selection algorithms. Note that this is necessary regardless of
> >    SEND; ingress filtering by itself will already cause this.
> >
> >    If the rights are the same for all routers, then current
> >    algorithms and SEND draft text are sufficient.
>
> I really don't care what preferences or other
> parameters routers advertise their
> capabilities as for default router selecation, so
> long as they are certified to route the prefix
> which I have as my source address.
>
> The trust which the host has of the delegation/certifcation
> should be sufficient to determine if the router is considered
> OK for routing.
>
> If there's no delegated authority for a particular prefix
> in the DCA, there shouldn't be any default routing
> through that router, regardless of the RA contents.
>

Yes, I agree with Greg here. The certificate contains the prefixes which the
router is authorized to filter. Exactly how advertising is done is a
question of how the ISP wants to configure their routers.

> >
> > (2) Are the advertised prefixes the same as the routing rights?
> >
> >    I don't they need to be. Clearly, we are not going to drop a RA
> >    just because it contains less prefixes than the router's cert.
> >
> >    Advertised prefixes should be a subset of routing rights.
>
> I think that for a particular security domain (for example
> a set of access networks) a router may be default for,
> I'd consider having a single 'default routing' certificate
> over those prefixes in the domain (which may be on several
> of the router's interfaces).
>
> In this case, the router's advertisment on a particular
> interface will not contain all of the prefixes, although the
> DCA would.  I'd guess that this could be a fairly
> common deployment scenario for wireless access networks.
>
> If this raises sacreligious horror in anyone, I'll be
> happy to recant if someone will tell me why this is bad.
>

Actually, this sounds as if it could be a very common case for ISPs - the
cert contains a collection of prefixes covering a number of subnets.

>
> > (3) What is the priority between the routing rights information and
> >    other factors?
> >
> >    Both routing rights and route information option, if not obeyed,
> >    can lead to dropped packets. Ingress filtering can drop packets
> >    with inappropriate source addresses, and disobeying a route
> >    information option can lead to a packet being sent to the wrong
> >    interface and network, with no guarantee that this networks can
> >    actually route the packet. So I would say that both factors are
> >    crucial. Inconsistency is possible, but is a configuration
> >    problem. Even without SEND, this can occur: host picks wrong
> >    source address, follows RI, packet discarded (either router config
> >    problem or host address source selection table config problem).
> >
>
> I'd actually guess that the routing rights guarantee
> that the router will not apply ingress filtering to your
> packet _if_ on that interface, it advertises that prefix.
>

Yes, I think that is accurate. However, I don't think the converse is
implied, that is, if the router doesn't advertise the prefix but it is in
the certificate, that the router won't filter.

So I suppose the route MUST filter on what it advertises, and SHOULD filter
on what's in the certificate if other routers on the link advertise other
prefixes. This would allow the case that Mohan is concerned about. If other
routers on the link don't advertise other prefixes, then the router SHOULD
restrict filtering to what it advertises.

Hmm, is this opening up things too much from a security standpoint?

> Assuming otherwise means one of two things:
>
> Hosts may choose to send to a router with a prefix it
> are authorized to route, on an interface relevant to a different
> prefix (... should this packet be ingress filtered?).
>
> Or
>
> Authorization must be done on a per-interface basis
> through certification of a CGA or otherwise.
> (This is OK, but I guess there's could be a lot of
> certificates if this was done naively).
>
> Certainly it's worth taking this to the IPv6 list,
> but I'd guess we'd have to be clear about how these
> certificates are interpreted and authorized.
>

> > Is there a need to talk about this in the IPv6 list? James?

Let's run it by the ADs first. I'll ask.

            jak

--------------------------------------------------------------------
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: Gregory Daley <[email-masked]>
Date: Sun, 04 Jan 2004 22:06:22 +1100

Hi Jari, 

Sorry I've dropped out of the conversation for a
while, but I've been looking at some of these issues
a recently, so I've got some ideas.

----- Original Message -----
From: [email-masked]
Date: Saturday, January 3, 2004 1:05 am
Subject: Re: issue 44 - host to check its own address against router 
cert prefixes?

Or

Greg