Re: multihoming, was IPv10

Mark Andrews <marka@isc.org> Fri, 30 December 2016 02:32 UTC

Return-Path: <marka@isc.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24160129A37 for <ietf@ietfa.amsl.com>; Thu, 29 Dec 2016 18:32:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.001
X-Spam-Level:
X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 kvVATpvTQ2Kx for <ietf@ietfa.amsl.com>; Thu, 29 Dec 2016 18:32:40 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 0C18B129507 for <ietf@ietf.org>; Thu, 29 Dec 2016 18:32:40 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 5F5E41FCAC5; Fri, 30 Dec 2016 02:32:32 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 0BFE116004F; Fri, 30 Dec 2016 02:32:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DF6AF16006B; Fri, 30 Dec 2016 02:32:30 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id V5OJdneNqhNg; Fri, 30 Dec 2016 02:32:30 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 5462E16004F; Fri, 30 Dec 2016 02:32:30 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 52CE25E161B5; Fri, 30 Dec 2016 13:32:27 +1100 (EST)
To: "John R Levine" <johnl@taugh.com>
From: Mark Andrews <marka@isc.org>
References: <20161229162721.34651.qmail@ary.lan> <20161230015709.EF91C5E15F13@rock.dv.isc.org> <alpine.OSX.2.11.1612292057480.38763@ary.qy>
Subject: Re: multihoming, was IPv10
In-reply-to: Your message of "29 Dec 2016 20:58:46 -0500." <alpine.OSX.2.11.1612292057480.38763@ary.qy>
Date: Fri, 30 Dec 2016 13:32:27 +1100
Message-Id: <20161230023227.52CE25E161B5@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/pIo3UaxP2RGMgeJTJOJprsO5QCY>
Cc: IETF general list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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, 30 Dec 2016 02:32:41 -0000

In message <alpine.OSX.2.11.1612292057480.38763@ary.qy>qy>, "John R Levine" writes
:
> >> This is a big reason why providers don't implement BCP38.  A customer
> >> has one block of addresses from provider A and another from provider
> >> B.  In general each provider only knows about its own address block,
> >> but the traffic comes from both blocks, and the customers get rather
> >> annoyed if a provider doesn't accept their traffic.  ("If you don't
> >> want our $20K/month, we're sure we can find someone else who does.")
> >> Trying to keep track of what customer has what block of someone else's
> >> address space is hopeless, so they just turn off the filters for the
> >> multihomed customers.
> >
> > BCP38 should be automatable at the edge even with multihoming.  We
> > do have the technology to provide each customer with a CERT that
> > says they have been assigned this block of addresses.
> 
> We do?  References, please, preferablyt with the commands I type into my 
> router to automatically import and handle the certs.

John read what I said not what you think I said.

We do have the technology to provide a CERT to every customer.  See SIDR.
We do have the ablity it verfiy these CERT and use them with BGP. 
We should be able to do this with other protocols.
These CERTs could be used to generate BCP38 filters.  This could be all
automated.

We have people complaining that BGP38 is hard for multi-homing
because it is a manual process of verifying each customers address
allocation.  Once you have a verified allocation the rest really
is a mechanical process.  The building blocks now exist for it to
be easy.  We should be using them.  There is NOTHING stopping ISP's
generating these CERTs today.  Just passing a request to accept
these addresses signed with the CERT to the other ISP would
significantly reduce the amount work required as well as the amount
of fraudulent requests.  A fax with faked letter head is so much
more secure, not.

There are lots of brainy engineers at router vendors that could
design a scheme to remove humans from this process.  I can think
of several methods to do this but I'm not a router vendor so I
don't have the ability to materialise the idea.

Mark

> R's,
> John
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org