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
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
