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

joel jaeggli <joelja@bogus.com> Thu, 31 December 2015 17:51 UTC

Return-Path: <joelja@bogus.com>
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 1083E1A8958 for <ietf@ietfa.amsl.com>; Thu, 31 Dec 2015 09:51:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level:
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Bu-Kn1W0GNeJ for <ietf@ietfa.amsl.com>; Thu, 31 Dec 2015 09:51:57 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A96F1A894E for <ietf@ietf.org>; Thu, 31 Dec 2015 09:51:57 -0800 (PST)
Received: from mb-2.local ([IPv6:2601:1c0:c102:22fb:b1f0:895a:628c:ab66]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id tBVHpoH7088893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 31 Dec 2015 17:51:50 GMT (envelope-from joelja@bogus.com)
Subject: Re: What to improve? BCP-38/SAC-004 anyone?
To: Patrik Fältström <paf@frobbit.se>, ietf@ietf.org
References: <7664F94E-F7A6-4556-B1E6-2DE536A7B7FC@frobbit.se>
From: joel jaeggli <joelja@bogus.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <56856B35.9090202@bogus.com>
Date: Thu, 31 Dec 2015 09:51:49 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Thunderbird/42.0
MIME-Version: 1.0
In-Reply-To: <7664F94E-F7A6-4556-B1E6-2DE536A7B7FC@frobbit.se>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="uNErxsdpgL43WV68q0UPPthhavNT3moET"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/sPb9VMnl2lZFbQbGoX6Ic4TUrTA>
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: Thu, 31 Dec 2015 17:51:59 -0000

On 12/30/15 9:16 PM, Patrik Fältström wrote:
> Jari,
> 
> Thank you for the blog post, and of course as co-chair of the ICG
> working on the IANA Transition I fully support and want to emphasize
> your last bullet, that we need to finalize the IANA transition, finally.
> 
> But, I want to mention one detail you might have hidden in one of your
> other bullets, although not explicitly, and that is one we in the
> Security and Stability Advisory Committee of ICANN where I am chair have
> been struggling with for years, and that is source address validation
> (for IP addresses that is). In the IETF there is the well known BCP-38
> that for various reasons is questioned, although "implement BCP-38" is a
> statement used for "do whatever is needed". In SSAC we already in 2004
> created SAC-004
> <https://www.icann.org/en/system/files/files/sac-004-en.pdf> about
> "Securing the Edge". The main author of SAC-004, Paul Vixie, and others
> have after that written numerous other documents on the same topic.

Strict URPF filtering relied on to two convenient fictions:

One that the forward and reverse path, both, carry the route for the
originating prefix. Cases where where this is not the case are both
ubiquitous and totally normal.

Two that URPF is simple to implement in hardware, scales well on all
architectures, and has little cost with respect to forwarding. Simply
put it does not.

While we might choose to restrict our definition of edge filtering to
the single-homed customers of retail ISPs, there are rather a lot of
those. There is on the other hand a plurality of transit ISPs that
cannot implement BCP 38 as envisioned or even something close to it.

> Baseline is, we must do something about it. For some definition of "we"
> and some definition of "something".
> 
> This is of course related to what Fred Baker brought up, that we do have
> some tools, but they are not deployed. And if they are deployed, they
> are not deployed to the degree and quality needed to give the intended
> effect.
> 
> We do have internationalized email addresses, we do have DNSSEC, we do
> have IPv6, we do have...but how much of this is deployed?
> 
> I am sorry to say I see even here on this list many people not using
> technologies they argue about. If I take things I have some clue about,
> I think, DNS, and check the domain names used for the conversation,
> neither DNSSEC, nor IPv6 or any other by the IETF after RFC1035 invented
> technology that is DNS related is in use. By the very same engineers
> discussing how to move standards forward. Is that a sign, or at least
> indication?
> 
> Back to the source address validation issues. That the edge can source
> IP packets with fake source IP addresses is a problem. It is, I claim,
> the by far largest problem we have today.
> 
> Is this connected to the fact that not even people developing standards
> use very same standards?
> 
> Has the IETF ended up being too academic and lost connection to what is
> actually deployed?
> 
> Sure, this gap between what is developed in the IETF and what is
> deployed has always existed. Existed when I started be wg chair,
> continued when I was an AD, continued even more when I was on IAB, and
> later ISOC BoT, and now SSAC Chair. And some of the RFCs I have written
> has been excellent examples of standards never taking off(!).
> 
> So yes, I blame myself for not having answers to my own questions. If I
> had, I would have pushed for the answers. I have at least myself
> working(?) PGP, DNSSEC, IPv6, NAPTR and many other things. I.e. I am, I
> claim, eating my own dog food.
> 
> But, is the taste of our own food so bad we do not eat it ourselves?
> 
> If so, how can we make others eat it?
> 
> At least some flavor of BCP-38?
> 
> Because that is really really the largest issue we have today.
> 
> With this, all the best for a successful 2016!
> 
>    Patrik Fältström
>