Re: IP Block 99/8 (DHS insanity - offtopic)

["Chris L. Morrow" <christopher.morrow () verizonbusiness com>]

On Mon, 23 Apr 2007, Stephen Sprunk wrote:

> Thus spake <bmanning () karoshi com>
> > On Mon, Apr 23, 2007 at 05:23:03PM -0400, Sandy Murphy wrote:
> > > You might try taking a look at the various presentations at
> > > NANOG/RIPE/ARIN/APNIC/APRICOT about the whole idea.
> > > Central point: the entity that gives you a suballocation of its
> > > own address space signs something that says you now hold it.
> > >
> > > No governments involved.
> >
> > no problemo...  when i hand out a block of space, i'll expect
> > my clients to hand me a DS record ...  then I sign the DS.
> > and I'll hand a DS to my parent, which they sign.
> > That works a treat.... today (if you run current code)
> > and gives you exactly what you describe above.
>
> That roughly matches what I expect, but the process seems backwards.  If
> IANA hands, say, 99/8 to ARIN, I'd expect that to come with a certificate
> saying so.  Then, if ARIN hands 99.1/16 to an ISP, they'd hand a certificate
> saying so to the ISP, which could be linked somehow to ARIN's authority to
> issue certificates under 99/8.  And so on down the line.  Then, when the
> final holder advertises their 99.1.1/24 route via BGP, receivers would check
> that it was signed by a certificate that had a verifiable path all the way
> back to IANA.
>
> Of course, one must be prepared to accept unsigned routes since they'll be
> the majority for a long time, which means you still run afoul of the
> longest-match rule.  If someone has a signed route for 99.1/16, and someone

keep in mind that the first step didn't include any real 'routing
protocol' hooks as I recall, but some automation help and OSS/ops help to
look over a long list of prefixes in a better manner. With some assurance
that the allocations/assignments were all proper... (and that hopefully
the customer was really the person authorized to use the ip space)

> else has unsigned routes for one or more (or all) of 99.1.0/24 through
> 99.1.255/24, what do you do?  Do you block an unsigned route from entering
> the FIB if there's a signed aggregate present?  Doesn't that break common

that sounds like sBGP/SoBGP ... of those the (last I saw) soBGP route of
using the certification information as a policy knob seemed the most
reasonable.