Re: multihoming, was IPv10

In message 
<alpine(_dot_)OSX(_dot_)2(_dot_)11(_dot_)1612292057480(_dot_)38763(_at_)ary(_dot_)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(_at_)isc(_dot_)org