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

Jari Arkko <jari.arkko@piuha.net> Mon, 04 January 2016 15:37 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C191A88E4 for <ietf@ietfa.amsl.com>; Mon, 4 Jan 2016 07:37:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.09
X-Spam-Level: *
X-Spam-Status: No, score=1.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcz2tS5r7G7q for <ietf@ietfa.amsl.com>; Mon, 4 Jan 2016 07:37:41 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id DAAC01A89A1 for <ietf@ietf.org>; Mon, 4 Jan 2016 07:37:40 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BE0F32CED2; Mon, 4 Jan 2016 17:37:39 +0200 (EET) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDsGDNEDhEEQ; Mon, 4 Jan 2016 17:37:39 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 236662CCAE; Mon, 4 Jan 2016 17:37:39 +0200 (EET) (envelope-from jari.arkko@piuha.net)
Subject: Re: What to improve? BCP-38/SAC-004 anyone?
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_9EEA5411-F3F6-4F81-9F67-658A8E9BDC7C"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5.1
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <DE81772E-22BA-45CE-A1B8-9E1BB34C0460@puck.nether.net>
Date: Mon, 04 Jan 2016 17:37:36 +0200
Message-Id: <1DA0624A-E022-4DE8-A4B4-59213FAFC468@piuha.net>
References: <7664F94E-F7A6-4556-B1E6-2DE536A7B7FC@frobbit.se> <5684FCDB.7010009@mnt.se> <A074CA07-691E-41A7-B1D7-33F4ECBED5A9@puck.nether.net> <568579FB.6030702@gmail.com> <DE81772E-22BA-45CE-A1B8-9E1BB34C0460@puck.nether.net>
To: Patrik Fältström <paf@frobbit.se>, Jared Mauch <jared@puck.nether.net>, huitema@huitema.net
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/_qZK_F9GveQt83MpyNnAYHHns1A>
Cc: IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jan 2016 15:37:43 -0000

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