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

"Patrik Fältström " <paf@frobbit.se> Thu, 31 December 2015 14:28 UTC

Return-Path: <paf@frobbit.se>
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 D152B1A88EA for <ietf@ietfa.amsl.com>; Thu, 31 Dec 2015 06:28:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.439
X-Spam-Level: *
X-Spam-Status: No, score=1.439 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, 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 dC9u4SjCTV6Z for <ietf@ietfa.amsl.com>; Thu, 31 Dec 2015 06:28:47 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3DB1A88E9 for <ietf@ietf.org>; Thu, 31 Dec 2015 06:28:47 -0800 (PST)
Received: from [192.168.1.118] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 8FF911FFD6; Thu, 31 Dec 2015 15:28:44 +0100 (CET)
From: Patrik Fältström <paf@frobbit.se>
To: "tom p." <daedulus@btconnect.com>
Subject: Re: What to improve? BCP-38/SAC-004 anyone?
Date: Thu, 31 Dec 2015 15:28:43 +0100
Message-ID: <758209BC-CDB8-4D81-B72A-DFA4FE568F29@frobbit.se>
In-Reply-To: <009b01d143c1$1508c360$4001a8c0@gateway.2wire.net>
References: <7664F94E-F7A6-4556-B1E6-2DE536A7B7FC@frobbit.se> <009b01d143c1$1508c360$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_E284AE3A-5B18-49D8-8C17-15FD2C0B69E9_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
X-Mailer: MailMate (1.9.3r5187)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/_bx0-yU3bfvjPNp-rOxeFEUp4mg>
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: Thu, 31 Dec 2015 14:28:49 -0000

On 31 Dec 2015, at 12:31, tom p. wrote:

> IP addresses are only meaningful to geeks like us.  Users at large see
> and use e-mail addresses and phone numbers and, when they have yet to
> learn that these can be faked, are susceptible to fraud.  This brings
> real pain to real people and could provide a lever to get things done.

You are correct on the difference between what is an issue to "normal people" and what is an issue "to us".

And yes, the issues with untrust in SS7, similar to the breakdown I see in X.509 CA environment, is hurting users. Makes it quite hard to set up a 2-factor authentication with recovery mechanisms being secure and trusted (i.e. hint: do not use the same telephone number for your 2-factor authentication as your fallback mechanism).

But not at all hurting the Internet as much as source IP address validation.

Given the depletion of IPv4 address space, we now see increased number of real use of allocated but not announced IPv4 address space. Simply because trust in routing make it easier to just use some space that no one else is using than pay $12/address or whatever it is.

This reuse of already allocated (by others) IPv4 address space has grown faster than I expected.

In the next phase, unless people use IPv6, people will just use whatever IPv4 addresses they can find. And that will hurt the ones having IPv4 addresses in the outskirts of the net. In developing countries. What do an organization in Sweden care if they just reuse whatever some organization in Rwanda use? If announced from Sweden, the addresses will probably work quite well for the Swedish organisation, but so much less for the one in Rwanda which is the real holder of the address space. Creation of local caches from Akamai, Google, Apple, Microsoft, Cloudflare and DNS operators as us as Netnod that moves content closer to Rwanda will for this scenario make the impact smaller. When it hurts. Not if.

Without proper source address validation, it will be worse than a cold on New Years Eve (which I understand many have), and we can never recuperate the situation we sort of have today -- that we can trust the uniqueness and correct (well) route announcement of IPv4.

And THIS is for me the largest driver for IPv6.

That we can not guarantee for how long IPv4 will actually work. For some definition of "we" and some definition of "work".

I am scared.

Really scared.

And if we loose this, then our fight against spam and other for the consumer visible things does not matter.

At all.

   Patrik