North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: IP Block 99/8 (DHS insanity - offtopic)
On Mon, 23 Apr 2007, Stephen Sprunk wrote: > > Thus spake <bmanning@xxxxxxxxxxx> > > 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.