On Dec 1, 2008, at 4:12 PM, Sandra Murphy wrote:

The issue in incremental deployment is not what the people who haven't deployed it should do but what the people who DO deploy it should do. What do the people who DO understand ROAs(and BOAs) do when they see something unsecured - it might be legit, just not produced by someone who understands ROAs(BOAs).

Right, but if the owner also published a BOA about who they
should not accept it from - what's the value add for those
who have deployed it again?  They can say, ohh, there's a ROA
for AS 1 to originate 10.0.0.0/8.  They also published a BOA
for AS2 to originate 10.0.0.0/16.  So, what's that mean to me
since I deployed it?  Accept 10.0.0.0/8 only from AS 1.  I'm
not going to put a policy in my router that says AND accept
it from anyone else, or any more specific, except AS 2.  Tracking
those BOAs is costing money (hardware, time, complexity) and
there is no added benefit.

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.

So it seems you are in the "and that's all" camp in interpreting ROAs, right?

No, I'm in the "show-me-how-to-configure-this-in-a-router-and-
convince-me-that-all-the-complexity-and-added-infrastructure-is
worth-the-investment-when-I'm-pretty-sure-I'd-be-just-as-happy
with-an-'explicit accept'='implicit deny'-model-like-all-my-other-
security-policies" camp.

I'm certain that if more people who are supposed to deploy this
stuff were paying attention they'd be making the same arguments,
but they're not, and so we need to give heavy consideration to this.

Does your answer assume operators are using ROAs to produce route filters?

Maybe.

Does your answer change if operators are using ROAs in the decision procedure, as presented at the last meeting?


Maybe.

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

Reply via email to