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
- What to improve? BCP-38/SAC-004 anyone? Patrik Fältström
- Re: What to improve? BCP-38/SAC-004 anyone? Leif Johansson
- Re: What to improve? BCP-38/SAC-004 anyone? tom p.
- Re: What to improve? BCP-38/SAC-004 anyone? Patrik Fältström
- Re: What to improve? BCP-38/SAC-004 anyone? Kathleen Moriarty
- Re: What to improve? BCP-38/SAC-004 anyone? Jared Mauch
- Re: What to improve? BCP-38/SAC-004 anyone? Leif Johansson
- Re: What to improve? BCP-38/SAC-004 anyone? Jared Mauch
- Re: What to improve? BCP-38/SAC-004 anyone? joel jaeggli
- Re: What to improve? BCP-38/SAC-004 anyone? Steve Crocker
- Re: What to improve? BCP-38/SAC-004 anyone? Brian E Carpenter
- Re: What to improve? BCP-38/SAC-004 anyone? joel jaeggli
- Re: What to improve? BCP-38/SAC-004 anyone? Jared Mauch
- Re: What to improve? BCP-38/SAC-004 anyone? John Levine
- Re: What to improve? BCP-38/SAC-004 anyone? Jared Mauch
- Re: What to improve? BCP-38/SAC-004 anyone? Michael Richardson
- Re: What to improve? BCP-38/SAC-004 anyone? Michael Richardson
- Re: What to improve? BCP-38/SAC-004 anyone? Michael Richardson
- Re: What to improve? BCP-38/SAC-004 anyone? Jared Mauch
- Re: What to improve? BCP-38/SAC-004 anyone? Jared Mauch
- Re: What to improve? BCP-38/SAC-004 anyone? Patrik Fältström
- Re: What to improve? BCP-38/SAC-004 anyone? Randy Bush
- Re: What to improve? BCP-38/SAC-004 anyone? Patrik Fältström
- RE: What to improve? BCP-38/SAC-004 anyone? Christian Huitema
- Re: What to improve? BCP-38/SAC-004 anyone? John Levine
- Re: What to improve? BCP-38/SAC-004 anyone? Jari Arkko
- Re: What to improve? BCP-38/SAC-004 anyone? Donald Eastlake
- Re: What to improve? BCP-38/SAC-004 anyone? Jim Gettys
- Re: Fwd: What to improve? BCP-38/SAC-004 anyone? dave taht
- Re: What to improve? BCP-38/SAC-004 anyone? George, Wes