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

"Christian Huitema" <huitema@huitema.net> Fri, 01 January 2016 19:52 UTC

Return-Path: <huitema@huitema.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 BAF8A1A8A13 for <ietf@ietfa.amsl.com>; Fri, 1 Jan 2016 11:52:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.1
X-Spam-Level: *
X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 KAFZwA9i5Wtf for <ietf@ietfa.amsl.com>; Fri, 1 Jan 2016 11:52:03 -0800 (PST)
Received: from xsmtp12.mail2web.com (xsmtp12.mail2web.com [168.144.250.177]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819D11A8A10 for <ietf@ietf.org>; Fri, 1 Jan 2016 11:52:03 -0800 (PST)
Received: from internal.xmail03.myhosting.com ([10.5.2.13] helo=xmail03.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <huitema@huitema.net>) id 1aF5ja-0008VE-W5 for ietf@ietf.org; Fri, 01 Jan 2016 14:52:02 -0500
Received: (qmail 1872 invoked from network); 1 Jan 2016 19:51:33 -0000
Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender <huitema@huitema.net>) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for <ietf@ietf.org>; 1 Jan 2016 19:51:32 -0000
From: Christian Huitema <huitema@huitema.net>
To: 'Randy Bush' <randy@psg.com>, "'\"Patrik Fältström\"'" <paf@frobbit.se>
References: <7664F94E-F7A6-4556-B1E6-2DE536A7B7FC@frobbit.se> <56856B35.9090202@bogus.com> <1C7E4F9C-C1D4-4383-98D8-65D48CC7BEE8@frobbit.se> <m2k2ntg0zx.wl%randy@psg.com>
In-Reply-To: <m2k2ntg0zx.wl%randy@psg.com>
Date: Fri, 01 Jan 2016 09:51:37 -1000
Message-ID: <000401d144cd$d522d7f0$7f6887d0$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQDxZTxoR0JcRa4ETe1miEEauanzQQFNC5qVAcHdGrIA198mc6CHkpDg
Content-Language: en-us
Subject: RE: What to improve? BCP-38/SAC-004 anyone?
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/VIxm5tVrPpIGaRUOnIuNIRvJCXc>
Cc: 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: Fri, 01 Jan 2016 19:52:04 -0000

On Thursday, December 31, 2015 10:25 PM, Randy Bush wrote:
> ...
> and, in the meantime, ietf idealists can continue to blame operators,
> operators can continue to blame vendors (and ietf idealists), and
> vendors can ask where the cash comes from.  and therein lies the
> disconnect.  the pain is far removed from the basic causes.  this
> generally does not work out very well.

It is pretty clear that BCP 38 is not being deployed because the incentives
are not there. Implementing ingress filtering on the current hardware
doubles the per packet processing time, and that's certainly a disincentive
for operators. It also creates new failure modes for ISP serving multi-homed
customers, and that too is a serious disincentive for operators. In short,
BCP 38 requires operators to increase their cost of operation in order to
protect "the whole Internet" against some forms of attacks. We can call it
tragedy of the commons or whatever, but the reality is that this kind of
mandate almost never gets deployed.

I can think of only one example of such mandates actually being enforced -
the fight against "open mail relays" a dozen years ago. The self-appointed
Internet police, or vigilantes, detected SMTP relays that could forward
spam, shamed them, and blacklisted them until their fixed their setup. The
relay operators could fix their operation, or face customer complaints that
their mail was being rejected. It was bitter, but there are very few open
mail relays left operating now, so in a sense we could say that vigilantism
did work. On the other hand, it is not like spam disappeared.

I shudder at the idea of vigilantes trying to enforce BCP-38 that way. Randy
gently pointed out the disconnect between operators and idealists. An
enforcement campaign complete with blacklists and BGP blocks would do
wonders for that disconnect! Besides, it would only work if we could also
secure BGP, another interesting problem. And even if it "worked," it would
probably not stop denial of service attacks, just like shutting down open
mail relays did not fix spam.

The realist view is thus to deprecate BCP-38. We tried, and we now know that
it cannot be deployed, and certainly cannot be relied on to stop attacks. 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!

-- Christian Huitema