Re: TWC (AS11351) blocking all NTP?

[Michael Smith <mksmith () mac com>]

On Feb 4, 2014, at 8:52 AM, William Herrin <bill () herrin us> wrote:

> On Tue, Feb 4, 2014 at 11:23 AM, Jared Mauch <jared () puck nether net> wrote:
> > On Feb 4, 2014, at 11:04 AM, William Herrin <bill () herrin us> wrote:
> > > If just three of the transit-free networks rewrote their peering
> > > contracts such that there was a $10k per day penalty for sending
> > > packets with source addresses the peer should reasonably have known
> > > were forged, this problem would go away in a matter of weeks.
>
> > I've seen similar comments in other forums.  We are all generally paid
> > for moving packets, not filtering them.  The speed at which you can forward
> > packets can often cause increased $$.  Using these features also impacts
> > performance, so the cost may actually be 2x in capex+opex to provision ports
> > due to reduced line-rate capability.
>
> Hi Jared,
>
> You're gonna need a bigger TCAM, but even so  I think you're
> overstating the case.

No, he's not.  The intelligence required to analyze packets is in addition to the intelligence required to move them.  
More packets, more cost.

> > Even if you take a RPSL-IRR approach to building filters, and even if the router
> > can handle such long ACLs bug-free, you have some objects that expand to
> > cover 50-90% of the internet. They may be someones backup route at some
> > point because of 'something'.
>
> Yes, but that's OK. In order to make sure that they're aren't
> originating from the penalizing 10%, your peers will have to implement
> similar filtering downstream... where the breadth isn't 90%.

So who determines this break point?  Who is responsible for a full-table Tier-1 to Tier-1 peering link?  Who polices 
it?  Who arbitrates disputes?


> > Clearly putting the filters as close to the source is helpful but detecting the
> > actual spoofed packet is hard.
>
> At the customer boundary it's trivial: they'll tell you what they
> originate, and that's what you'll allow. If your customer lies, pass
> the penalty forward.
>
> At the peering boundary, you don't have to detect the forged packets.
> You can wait until someone complains, confirm it, and then apply the
> penalty. Packets coming from your peers won't
> go to your other peers, only to your customers. That's how you rigged
> your routing. More, evidence that the downstream was authorized to
> send those packets refutes the penalty.

You know this is completely unworkable at scale right?

> > Until you find yourself on the receiving end of these types of things, you may not
> > ask for or pay for DDoS protection services, or advanced filtering, or even ask
> > your vendor to support these features.  I have to wait months for fixes in the
> > features because no support from others in the industry on the platform, etc.
>
> DDoS is a bigger problem than spoofing and amplification.  My
> suggestion only addresses spoofing and amplification, not botnets in
> general.

But they have the same economic inputs, yes?  As Jared said, providers get paid by the bit.  Many (most?) Bad Actors 
get paid by the bit, Vendors get paid by the bit, mitigation vendors get paid by the bit.  That's a lot of dollars for 
a lot of bits and they increase together.
> > Those that are up in arms about this stuff seem to not be the ones asking
> > the vendors for features and fixes.
>
> Like I said, the "tier 1's" can't be the source of the solution until
> they stop being part of the problem.

You are asking the guys who build and maintain the highways to be responsible for checking every car on the road to see 
if it's carrying illegal drugs.  How can that possibly work?

Mike