WG Chair hat off
On 02/12/2008, at 9:34 AM, Danny McPherson wrote:
On Nov 25, 2008, at 6:39 PM, Geoff Huston wrote:
Sure. So here's some use cases of BOAs:
1. I have been allocated 203.10.61.0/24. I do not use it today in
any public routing context. It should not appear in BGP at all. I
do not give my authorization to any AS to originate a route for
this prefix, or any more specific of this prefix. If I generate a
BOA for 203.10.61.0/24 then my intention of saying that any use of
this prefix in the public Internet is unauthorized is clear.
If you do not give your authorization then do not issue a ROA.
With the incremental deployment argument, I'm not sure who would
be looking at BOAs if they're not looking at ROAs.
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 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.
2. I have been allocated AS 131074 as an AS number. I do not use it
today in any public routing context. It should not appear in BGP at
all either as an origination AS nor as a transit AS in any AS path.
If I generate a BOA for AS131074 then my intention of saying that
any use of this AS number in the public Internet is unauthorized is
clear.
But the draft currently does not mitigate "nor as a transit AS",
unless I'm missing something. Specifically:
S.5 graf 2:
"If a route object has an AS origination that refers to an AS number
that is listed in a valid BOA, then the route object can be regarded
as a Bogon object, and local policies that apply to Bogon AS's can
be applied to the object. This holds whether or not the address
prefix of the route object is described by a valid ROA or not."
I see nothing about "or as a transit AS" in there.
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.
3. I have been allocated 203.10.60.0/22. I wish to ensure that any
more specific advertisement of this prefix is unauthorized. If I
generate a BOA for 203.10.60.0/23 AND 203.10.62.0/23 then my
intention is clear.
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.
And a non-use case of BOAs:
4. I am a wholesale ISP, and while I allocate address space to my
clients from my aggregate address block (10.0.0.0/8) I also permit
my clients to use their more specific prefix at local exchanges. My
AS number is 131072 and I have generated a ROA for 10.0.0.0/8 ,
maxlength=8 origin AS 131072. I do not have a problem with more
specifics of 10.0.0.0/8 being used in routing contexts, as part of
my wholesale stance. I would prefer that my ROA did not cause my
customer's more specifics to be treated as unauthorized routes,
irrespective of whether they are ready to use a ROA today or not.
Geoff
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
