ietf
[Top] [All Lists]

Re: What to improve? BCP-38/SAC-004 anyone?

2016-01-04 09:38:00

Address spoofing indeed continues to be a scary problem, particularly
with the v4 space pressures that Patrik mentions.

Still, a couple of useful things to keep mind when looking at this problem.
First, break it down. It isn’t just one problem. For instance, my perception
is that in the consumer subscriber interface situation is pretty good. (But
stats would be useful, does anyone have data?) As you go towards
more complex cases, the cost and false positive problems start
to become significant, which has lead to the problems listed in
this thread. We may still usefully improve some aspects of the
problem. And different tools may apply to the different parts.

Second, I think we need to be realistic with deployment expectations.
I have a very hard time thinking of anything that would be universally
deployed everywhere. No matter how good it is. Deal with it.
This isn’t an excuse for bad solutions, but you have to set your
expectations differently, this isn’t your grandfather’s Internet
any more :-) it is big and not everyone wants to spend their
time updating. I also think some of our canonical examples
of deployment difficulties may need updates, see for instance
IPv6 connectivity for Google US customers [1] :-) I know
this isn’t the end state, but it also very significant, and with
a clear trend.

Third, this whole business reminds me of Marshall Rose’s note

   "once the cable is cut you don't need more retransmissions,
   you need a *lot* more voltage.”

If other people are sending junk your way, *you* don’t need a
new protocol, you need to make those people *care*.

I think the issues are more fundamental and about networking
incentives. I’m also in agreement with Christian’s point about
attacks moving up in the stack if you plug a particular hole at
a particular layer.

I wanted to mention also that for a long time we’ve had some
people in the IETF who wanted to go beyond what current
ingress filtering tools do. SAVI WG, for instance. But once
you have done the simple things, the set of people willing
invest further, e.g., to consider the more complex solutions
will be smaller. I’d love to see more work on this (as long
as everybody understands what they are getting, and the
tradeoffs.)

So what can we do? We can address some subparts of the
problem, e.g., below some ideas from the discussion. Also,
perhaps there’s some completely new idea that is obviously
going to solve this problem. If anybody has that, let the rest
of us know :-)

Jared wrote:

What I often need are better tools to trace back spoofed packets or mark 
them.  The
nice thing about most of these attack networks is they respond faster than I 
can trace
and most attacks we see are sub-15 minutes.  The incentives are all wrong 
here and
I’d love to talk to people about how to change them.  Some locations, eg: 
Finland
have a regulator that does not accept spoofing from the entities they 
supervise.

Christian wrote:

We already design new protocols with the assumption that the source IP address
can be forged. Let's fix the old ones. And in particular, let's fix DNS
implementations so they cannot be used as DDOS amplifiers!


Patrik wrote:

why not start with the single home customers. What about look at default 
configuration of CPEs and alike? What about...I just do not know. Something 
just must be done.

Jari

[1] https://www.google.com/intl/en/ipv6/statistics.html

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail