Re: aggregation & table entries

[Stephen Stuart <stuart () tech org>]

> > i've never seen a dns attack that didn't have 50% or more packets coming
> > from spoofed sources, though due to loose-mode uRPF, most spoofed sources
> > in the last year or so have been from addresses for which a route exists.
> > -- 
> > Paul Vixie
>
>       reiterating a sometimes heretical idea...
>
>       are you refering to things like  172.17.0.0/16 where
>       only a couple hundred of those numbers have real services, e.g.
>       all the services are in 172.17.22.0/24 and the spoofed addresses
>       are in 172.17.128.0/17 space?

In that example, if the receiver uses loose-mode uRPF to filter
ingress and carries within their AS only the minimal set of RFC1918
routes corresponding to their actual use of it, then spoofed-source
packets "from" 172.17.22.0/24 would be allowed in by loose-mode uRPF
because a route table entry exists. Packets "from" the rest of
172.17.0.0/16 would be filtered.

Loose-mode uRPF does not protect you from spoofed-source packets where
the source address falls within a prefix that you use internally,
whether that space is RFC1918 space or not.

Likewise, loose-mode uRPF does not (completely) protect you from
spoofed-source packets where the source address falls within a prefix
that is valid externally, not necessarily via the reverse path on
which you're receiving the packet.

The first can be addressed with additional filtering, as has been
mentioned. The second is a harder problem, because of the business
decisions of some providers to source packets from prefixes that they
do not announce.

>       or... why do people insist on injecting routes to non-existent
>       things?    a route table entry is a route table entry, regardless
>       of the scope.  

Is this where you advocate that providers only announce the parts of
their assigned blocks that are in use?

Stephen