[ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment)

[Taylor, Stacy]

Speaking only for myself, I believe it is absolutely not for the RIR to
police or monitor use of blocks.  The Registry is there for just that:  to
keep track of who is using what.  It must not be responsible for pulling
routes or revoking rights for abuse reasons.

The onus must ultimately be on the upstream operators to maintain the
integrity of the blocks: both for contiguity and for purity.

Stacy

-----Original Message-----
From: John M. Brown [mailto:john at chagres.net]
Sent: Tuesday, February 18, 2003 12:44 PM
To: ppml at arin.net
Subject: RE: [ppml] Abstract of proposed Internet Draft for Best
CurrentPractice (please comment)


once upon a time we tried to create a data base, RADB, IRR
etc.  They don't seem to be getting as much use as they
used to.

I am extremely leary of having the RIR's become involved
in "asserting" whats in the routing table.  

The failure modes of that database being corrupt, hacked
or fat finger'd are to big to justify the value of it,
IMHO.  If someone like ARIN did it I would expect them
to carry a liability policy of multiple millions incase
they fat fingered or other screwed the data up and cause
someone get get dropped off the net that wasn't suppose
to be.



> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On 
> Behalf Of Joe Provo
> Sent: Tuesday, February 18, 2003 1:23 PM
> To: John M. Brown
> Cc: ppml at arin.net
> Subject: Re: [ppml] Abstract of proposed Internet Draft for 
> Best CurrentPractice (please comment)
> 
> 
> 
> [similar to a rant half-written and not sent during nanog]
> 
> On Tue, Feb 18, 2003 at 10:35:33AM -0700, John M. Brown wrote:
> > no they don't  The ability to accept routes from a customer is 
> > strictly a matter between the service provider and its customer.
> [snip - we'll use this context later]
> > I can see a nice little DDOS vector here.  Happy Hacker tricks BGP 
> > into revoking EBAY's prefix, EBAY looses millions, sues RIR.
>  
> Straightforward denial of service, nothing distributed. And 
> guess waht - the black hats are already (have been for a while) 
> exploting longest-match as a way to impersonate routes/steal 
> traffic/smokescreen their black-hatted-ness. How does this 
> relate to RIRs? Through the side door:
> 
> - RIRs already have multihoming as a requirement for AS 
>   allocations.
> - Some RIRs have multihoming as address allocation 
>   justification. 
> ...seems that the RIR's are NOT 'controlling the routing table' 
> (but gosh, is there a problem with publishing allocation data 
> in standardized machine-parsable format? RIPE seems to do it 
> a-ok...) but DO have their fingers in the justification of 
> space and -to a limited degree- how that space is to be 
> utilized.
> 
> See it isn't the Vendor-customer relationship (well, except from 
> clueless vendors who think any routes they propagate are instantly 
> going to be "valid" because they are special/big/buy from 'all 
> the tier1s'/etc) so much as the customer-vendor-rest of the net.
> 
> It is a Very Short step to dedicating and policing space for 
> 'officially blessed small multihoming'. This would
> - be consistnt with RIR roles and previous actions (ASNs not 
>   used for multihomed entities can be revoked; ISPs and other 
>   LIRs are tacitly encouraged to revoke space that was 
>   justified by multihoming when said multihoming doesn't 
>   occur; etc)
> - reduce deaggregation/holes in areas populated by aggregates
> - give network operators additional tools to do *their* jobs 
>   of filtering/fighting black-hatted-ness *without* making it
>   the RIR's job (ie, i can filter against longest-match abuse 
>   in space knpown to be populated with aggregates AND point
>   any complainers to the Right Thing)
>   
> 
> Do I want the RIRs managing the routing tables? No. Do I 
> want registries to hold confirmed data, audit trails 
> disambiguated, and everyone playing by the same rules? Yes.
> 
> joe, not enough coffee so i hope this is coherent
> 
> -- 
>              RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
>