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

Jim Gettys <> Mon, 04 January 2016 16:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B6F581A8A47 for <>; Mon, 4 Jan 2016 08:28:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.423
X-Spam-Level: *
X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MnIZ4FzU6jpr for <>; Mon, 4 Jan 2016 08:28:12 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 154991A89AE for <>; Mon, 4 Jan 2016 08:28:12 -0800 (PST)
Received: by with SMTP id l65so169017448wmf.1 for <>; Mon, 04 Jan 2016 08:28:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=x8hYkCA2anre2lB/7JhuakAroeuyT9bW7pK3I7DWp7M=; b=Zb/5ApODXjCApduEmNuTwp9jXPVT8KZGQcGYWbVG2tcLnYGr5nyWSwW01M5aAdWDsW g97FYnEOkF+5zGNPpomfq0U8ImM587tRbqUegKlUX9D9/wKqkz90GtBqJRgXLy4W04S6 zwSxfHEhiYCiUwhb9rLvPQsUKLAnuwd/NXr+Puf7Ds/6WFI1cHMZzX7xPzprfY9jHWTN Bt8Qfng/ayl200UfODV2avGbhJSaHRLC4aPk1lDS0uu0r+1OizxTcVCkJEn5R3eORF7W 7eNHpp9zddIAo3dQIlRNdpbC1P4uyoQScd3y2YlQYEC7Zn/XkT+LYdHAP81NBRQrydca Y8vw==
MIME-Version: 1.0
X-Received: by with SMTP id cg18mr42809793wjb.117.1451924890639; Mon, 04 Jan 2016 08:28:10 -0800 (PST)
Received: by with HTTP; Mon, 4 Jan 2016 08:28:10 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Mon, 04 Jan 2016 11:28:10 -0500
X-Google-Sender-Auth: j7cBAKt88Ba1klGN1Tr_IlagbIw
Message-ID: <>
Subject: Re: What to improve? BCP-38/SAC-004 anyone?
From: Jim Gettys <>
To: Jari Arkko <>
Content-Type: multipart/alternative; boundary="047d7bfcf1c658e9510528849bea"
Archived-At: <>
Cc: Dave Taht <>, Jared Mauch <>, Christian Huitema <>, IETF discussion list <>, Patrik Fältström <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Jan 2016 16:28:14 -0000

On Mon, Jan 4, 2016 at 10:37 AM, Jari Arkko <> wrote:

> 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.
​Certainly CeroWrt (Dave Taht's version of OpenWrt where much of the
bufferbloat work was done) implements BCP38​. And a home router has to know
what address ranges it is responsible for routing; it makes sense to
delegate the home part of the problem to the home router.

Dave may be able to comment as to whether BCP 38's requirements cause any
compute issues in a home router, given the processors/software on those
devices. It was implemented using the usual Linux packet filtering

The bigger headache is the previously unsolved problem: the very slow
uptake from upstream sources and brokenness of home router market.   I
typically find a minimum of *four years* old firmware packages even on
*brand new *devices on the market, with little sign of security software

Here, ISP's that provide home routers could have leverage; but only if
ISP's are willing to make it a hard requirement on purchasing decisions
they make, rather than the currently observed behavior of buying from the
lowest vendor the junk they typically buy today.  The technical side of the
ISP's need to educate the business people that they are encouraging a "race
to the bottom" with possibly catastrophic consequences; BCP 38 is the least
of the problem. I'll take ongoing prompt security updates for the life of
devices such as home routers over BCP 38 any day, and if the devices
continue insecure, BCP 38 is moot, as an attacker will just take over the
router first.

As an industry, this is the bigger challenge.

For more information on the dysfunctional embedded market, see my Berkman
Center talk: