Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt

[Danny McPherson <[e-mail]>]

On Dec 1, 2008, at 4:00 PM, Geoff Huston wrote:

> I'm sorry, but I cannot see any logic in that response. If I do not  
> give my authorization and I would like to inform everyone else that  
> any use of this address, or this AS is an instance of a hijack

A hijack, that's new..  So, publish a BOA for each professed
hijack, so that when it's picked up 24 hours later folks can
filter based on a BOA?  It'll be interested to project how
folks would automate such a BOA publication model.

> then your response seems to be saying to me that I should not do  
> anything. If that is what you are saying then it seems to be a  
> totally ineffectual course of action in my opinion.

No, you're saying you're doing this to support incremental
deployment, I'm saying that capability doesn't exist today
and will clearly only complicate things down the road - e.g.,
who's ever going to remove a BOA - sound familiar (e.g., who
ever removes a stale IRR object, which is a positive thing)?
What existing capability are you adapting to RPKI?

> My apologies - we are not allowed to talk about transit yet as its  
> not an agreed requirement coming out of RSPSEC. So if I remove "nor  
> as a transit AS" and sundry words then I trust that the point I was  
> making is amply clear.

I don't consider it "sundry", it's a very important distinction,
and suggesting that BOAs add some capability that ROAs or SIDR
can't help with along the lines of looking for potential bogon
ASNs in a is misleading at best.

>> I still don't by it..  As an operator, you tell me who is authorized
>> to originate and that's the only origin AS I accept.  That's easier  
>> to
>> configure in a router, requires less objects in the RPKI, and makes  
>> life
>> much simpler.
>
> No security at all makes like enormously simpler.  At some point it  
> is necessary to understand what makes a robust security environemnt  
> even in a world of partial use and piecemeal adoptions and then work  
> through the issues related to operational deployment. But you appear  
> to have some other approach in mind.

Right, and adding new capabilities (e.g., telling everyone via
means that are clearly not real time, and may be delayed for
a day or more, via a global RPKI, that your route has been
hijacked and should NOT be advertised by Miguel in Mexico, it
just doesn't seem like a clean way to build this architecture to
me - especially when you're asking folks to configure routers or
implement control plane state and memory based on the contents
of this RPKI.

-danny
_______________________________________________
sidr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sidr