[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Tier 2 ingress filtering - folo

Quite a number of people have responded to this post.

But no one's actually addressed my key question:

----- Original Message -----
> From: "Jay Ashworth" <jra at baylink.com>

> In the current BCP38/DDoS discussions, I've seen a lot of people suggesting
> that it's practical to do ingress filtering at places other than the
> edge.
> My understanding has always been different from that, based on the idea
> that the carrier to which a customer connects is the only one with which
> that end-site has a business relationship, and therefore (frex), the
> only one whom that end-site could advise that they believe they have a
> valid reason to originate traffic from address space not otherwise known to
> the carrier; jack-leg dual-homing, for example, as was discussed in
> still a third thread this week.

Here's the important part:
> The edge carrier's *upstream* is not going to know that it's
> reasonable for their customer -- the end-site's carrier -- to be originating
> traffic with those source addresses, and if they ingress filter based on the
> prefixes they route down to that carrier, they'll drop that traffic...
> which is not fraudulent, and has a valid engineering reason to exist
> and appear on their incoming interface.

An edge carrier, to whom an end-site connects, *can know* that that particular
end-site will need an exemption, for reasons like non-BGP dual-homing or load-

But there's no way for an upstream transit carrier to know that *at the present

So, short of building another big RPKI infrastructure to authenticate it (which
isn't going to happen this decade) or getting lots of carriers to cooperate in
some other information exchange so they know where to poke extra holes (which 
isn't going to happen this decade), is there any way at all to actually do
ingress filtering at the transit level -- as many here advocate -- without
throwing out the baby of *valid* unexpected source addressed packets with the
bathwater of *actual* fraud?

IP packets with source addresses that don't match the address space of the interface
you got them on are *not* a 100.0% accurate proxy for fraud and attacks.

-- jra
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274