Tier 2 ingress filtering

Mailman List Mirror (Read Only)
1

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.

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.

Fixing that will require the construction of an entirely new tracking system
at the Tier 2, which is not really the case for the Tier 3 edge carrier,
as I see it - you generally just turn unicast-rpf on for everyone's port,
unless you have a signed waiver in your file cabinet, in which case
you turn it off.

Am I missing something?

Or is the overarching problem large enough that people are willing to
throw the baby out with the bathwater?

Cheers,
-- jra

2

is there a clear understanding of "the edge" in the network operations
community? in a simpler world, it was not that difficult, but interconnect
has blossomed and grown all sorts of noodly appendages/extentions. I fear
that edge does not mean what you think it means anymore.

/bill

3

For 5 9's worth of eyeball networks hanging off consumer-grade ADSL and cable
connections, it's still the edge and still trivially filterable. If that's a
problem, the ISP can upsell a business-class connection that doesn't filter. :wink:

4

Hi Jay,

There's a two part heirarchy of contracts involved in every legitimate
end-to-end communication which occurs over the Internet, right? You
buy service from someone who buys service on your behalf from someone
who buys service on his behalf from someone. The other endpoint does
the same, starting with his ISP. The contract hierarchies meet at the
top, either with a single backbone ISP or with a pair of backbone ISPs
who do settlement-free peering with each other.

So, you represent to your ISP that you're authorized to use a certain
range of addresses. He represents to his upstream that he's authorized
to use them on your behalf, and so on.

The reliability of these representations obviously falls at they grow
distant from the source. So what? That's a problem for RPKI. The
problem we need concern ourselves with is dropping packets whose
source addresses are inconsistent with our customer's _representation_
of the addresses he's authorized to originate, however reliable or
unreliable that representation may turn out to be.

Regards,
Bill Herrin

5

5 9s? I'll go w/ big, but this seems a stretch to me.
  if true (it might be), then filtering ought be done and
  catch the delta. I still posit a baseline that does not
  fit this lowhanging fruit... (trill networks, L2 transparent
  bridging, L2-L3-VPNs, etc.)

/bill

6

Question is, is it reasonable to expect customer to know what networks they
have.
If yes, then you can ask them to create route objects and then you can BGP
prefix-filter and ACL on them. I do both, and it has never been problem to
my customers (enterprises, CDNs, eyeballs).

But if your customer has many other transit customer it can quickly become
less practical. I'm sure for many/most customers of tier1 it would not be
reasonable expects to keep such list up-to-date.

You can't do it at top-level nor it's not practical to hope that some day
BCP38 is done in reasonably many last-mile port.
But there are only 6000 non-stubby networks, if you do it at network before
stubby network, it's entirely practical and maintainable, provided we'd
want to do it.

7

C'mon guys: the edge is where people who *source and sink* packets
connect to people who *move* packets. There may be some edges *inside*
carriers, but there is certainly an edge where carriers hook up customers.

And no, this should apply to business-grade connections as much as resi.

Cheers,
-- jra

8

From: "William Herrin" <bill@herrin.us>

So, you represent to your ISP that you're authorized to use a certain
range of addresses. He represents to his upstream that he's authorized
to use them on your behalf, and so on.

The former is a first-hand transaction: if you're lying to your edge
carrier, he can cut you off with no collateral damage.

The latter, though, is arms-length, *and* has no reasonable way to be
implemented that I can see without extending whatever OAM&P system
that carrier has atop their gear.

The reliability of these representations obviously falls at they grow
distant from the source. So what? That's a problem for RPKI. The
problem we need concern ourselves with is dropping packets whose
source addresses are inconsistent with our customer's _representation_
of the addresses he's authorized to originate, however reliable or
unreliable that representation may turn out to be.

That's great, but that's a couple orders of magnitude of added complexity
that, quite frankly Bill, I can't sell just now. :slight_smile:

Worse (to bring this ontopic for NANOG): that complexity needs to live
*inside routers*, unless I'm very much mistaken.

Cheers,
-- jra

9

Of course, he has to notice it first. :slight_smile:

ObOpinion: It's best to *enforce* a policy which disallows a
downstream network from sourcing spoofed packets -- and the closer to
the "edge" you are, the better, Hierarchy is great for that. :slight_smile:

I guess the next best thing is "Trust but verify"?

- ferg

10

From: "Saku Ytti" <saku@ytti.fi>

> 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...

Question is, is it reasonable to expect customer to know what networks
they have.

If by "customer" you mean the same thing I do: an end user who sources
and sinks packets, which is fed by some Internet Access Provider...

then my answer is the same thing it was before:

"No, but it doesn't matter, because we're talking about ingress filters
on the carrier which provides them with public address space, and *it*
*does* know which network they've been given."

If yes, then you can ask them to create route objects and then you can
BGP
prefix-filter and ACL on them. I do both, and it has never been
problem to
my customers (enterprises, CDNs, eyeballs).

You are at least 30,000 feet higher than the conversation I'm having.

BGP-speaking end sites are a whole different matter, and sufficiently
smaller in number (2-5 orders of magnitude, depending on what you sell)
that they're not really pertinent here.

But if your customer has many other transit customer it can quickly become
less practical. I'm sure for many/most customers of tier1 it would not
be reasonable expects to keep such list up-to-date.

Correct, and this was the substance of my question.

You can't do it at top-level nor it's not practical to hope that some
day BCP38 is done in reasonably many last-mile port.

I don't know that that's true, actually; unicast-rpf does, as I understand
it, most of the work, and is in most of the current firmware.

But there are only 6000 non-stubby networks, if you do it at network
before stubby network, it's entirely practical and maintainable, provided
we'd want to do it.

Your assertion is the thing for which I'm requesting support in this query.

Cheers,
-- jra

11

From: "Paul Ferguson" <fergdawgster@gmail.com>

> The former is a first-hand transaction: if you're lying to your edge
> carrier, he can cut you off with no collateral damage.

Of course, he has to notice it first. :slight_smile:

Sure.

ObOpinion: It's best to *enforce* a policy which disallows a
downstream network from sourcing spoofed packets -- and the closer to
the "edge" you are, the better, Hierarchy is great for that. :slight_smile:

Sure; that's sort of my point: this is *much* more effectively done at
the actual edge; I think the systemic complexity of pushing it further
in goes up as a log function -- meaning that the fact that there are
only maybe 6000 transit networks is a red herring.

I guess the next best thing is "Trust but verify"?

Always.

Cheers,
-- jra

12

> From: "Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>
> For 5 9's worth of eyeball networks hanging off consumer-grade ADSL and cable
> connections, it's still the edge and still trivially filterable. If that's a
> problem, the ISP can upsell a business-class connection that doesn't
> filter. :wink:

C'mon guys: the edge is where people who *source and sink* packets
connect to people who *move* packets. There may be some edges *inside*
carriers, but there is certainly an edge where carriers hook up customers.

Exactly - packets leaving Comcast's network and going to another tier 1/2,
the receiver may have a hard time figuring out if the packet is legit or not.
But it's trivial for Comcast to tell whether the packet that just came out
my cablemodem is consistent with what their DHCP server told my CPE.
(For the record, the last time I tried running the spoofer.sail stuff
on my home gear, it was totally unable to sneak a packet out, so at least
part of Comcast does this right).

And the fact that there's places where it *is* hard to deploy isn't an excuse
for not doing it in the 98% of places where it's a slam dunk.

And no, this should apply to business-grade connections as much as resi.

Oh, I was intending *those* would be filtered by default as well, but you
could request an opt-out if you were trying to do multi-homing on the cheap
as some people have suggested (similar to blocking outbound 25 by default,
unless the user actually has a mail server).

13

Yeah, that's what I meant: ingress filter all edge connections except maybe BGP, and accept optout requests.

14

Even if all of last mile devices support uRPF, which it does not, getting
all these 100s of millions of ports configured correctly does not strike as
practical goal.
Fixing 6000 non-stubby transit providers catering sufficiently small tails
is much more practical goal.

15

Saku,

all these 100s of millions of ports configured correctly does not strike as
practical goal.

It is practical, IMO, similar to configuring IP address/prefix (or QoS policies) on every port.

In fact, what makes it easier is that uRPF can be part of the template that can be universally applied to every edge port.

Fixing 6000 non-stubby transit providers catering sufficiently small tails
is much more practical goal.

Agreed.

Cheers,
Rajiv

16

There is incredible amount of L3 interfaces in the last mile, old ghetto
stuff, latest gen Cisco, which does not do uRPF.

17

Very true. Some of it you can even configure as such, it just doesn't
do anything...

Jeff

18

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

[snip]

Do you have a LOA on file for that peer/customer to route traffic to
(or from) the prefix?
If yes, then it's legitimate that they source traffic from it, or request
that the prefix be included in their filters for BGP and ingress controls.

If no, then consult the routing policy that applies to them.

Ingress source addresses should optimally ideally be filtered at
turnup to the list of authorized prefixes, if uRPF cannot be
implemented (uRPF is convenient, but not necessarily necessary to
implement ingress filtering), then access list based on source
address, even the nearly oldest of the most ghetto equipment should
be offering basic ACL functions.

If the downstream need extra prefixes that you couldn't have known
about, then it's the downstream network's job to contact you to have
the prefix added to filters, before they start sourcing traffic from
those addresses.

By definition if they wouldn't be allowed to route traffic _to_ that
address over your link, your network's routing policy documents could
and probably ought to say, that it's not allowed to source traffic
from such unauthorized addresses.

If the peer is your transit provider that is authorized to give you
default and route any prefix, then sure, allow any source, because
they are authorized (except source addresses that belong to your
network or your customers that have not secured your network's
permission to be multihoming with their link and specified address
space, of course)..

19

I tested several days ago and was surprised/impressed to find that my home cable provider does not allow me to spoof.

AFAICR, all of the Tier1/Tier2 providers I've dealt with over the years (UUNet, Sprintlink, C&W, MCI, Digex, Intermedia, Abovenet, Level3, TWTelecom, Cogent, BHN, I'm probably forgetting a few) have done BGP prefix-list filters on their transit customers. If they know what routes you might want to announce to them, wouldn't it be reasonable to use that same list of prefixes (in the vast majority of cases) as the basis for an input ACL on your interface?

It'd be extra work for the T1/T2 networks to do this, and arguably, all the customer networks should be doing it inside their own networks, but we all know that not everyone who buys a connection and configures BGP has half a clue, and for the ones that do, we can all appreciate the idea of a belt and suspenders.

It's time for people to stop passing the buck on BCP38 (we don't do it, because it really ought to be done at that other level) and start implementing it where possible.

20

See below

Jared Mauch