On Tue, 2 Dec 2008, Geoff Huston wrote:
WG Chair Hat OFF
On 02/12/2008, at 11:05 AM, Pradosh Mohapatra (pmohapat) wrote:
Hi Geoff,
| >> 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.
What if: when "I have been allocated 203.10.61.0/24", I issue an
ROA for the same with my origin AS? Doesn't that automatically
mean that all the advertisements of the prefix from another origin
AS are automatically invalid?
No. Some folk believe that this should be the case, others believe that this
should not be the case. Those who believe that this should not be the case
are proposing the BOA as a form of explicitly stating what is invalid
without having to state what is valid.
Can you explain why you think it better to say what is invalid rather than
stating what is valid?
By the way, given that you have published a ROA aithorizing your origin AS to
advertise the prefix, I suspect that this has created some further
vulnerabilities that a BOA would not create. What happens if I use this ROA
you've created to hijack with your prefix by prepending your origin AS to my
AS? Can a third party detect that this is a hijack of your prefix from the
origination information and the ROA? I do not think so.
We all recognize and acknowledge that the sidr work does not protect
against those who want to append the valid origin on an invalid path.
The sidr work protects the origin of the AS_PATH only, and does not
provide protection of the validity of the rest of the AS_PATH.
Recognize that protection of the origination of the route is NECESSARY.
Everything we do here is needed by any protection of the full AS_PATH
developed some time in the future.
And since I will not be generating
any updates for this prefix, it will not appear in BGP at all!
Doesn't that solve the problem you cited?
no - see above,.
Please explain further. It appears to me that if you take the "these ASs
and that's all" interpretation of a set of ROAs, an AS that produces one
ROA does prevent other ASs from advertising the prefix (and being
believed).
Are you concerned that
some other AS would also issue an ROA for the same or a more
specific block of the prefix? That can't be!
| >> 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.
How important is the case of "AS protection" as opposed to
"prefix" protection? Doesn't this automatically become a
by-product of ROA level checks?
No, it does not. There are many instances of use of AS numbers what are not
recorded in any allocation database. See the attached list for today's set of
bogon ASs
Who would sign the BOAs for unallocated ASs? (I don't know. RIRs? How
would that work -- would such a BOA have to change with each new
allocation? Would there be a BOA for each unallocated AS that would be
revoked when it was allocated?)
| >> 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.
As others have suggested, when "I have been allocated 203.10.60.0/22",
I issue an ROA for 203.10.60.0/22-22. That automatically means that
there can't be any other advertisements for this prefix or its more
specifics (unless I suballocate a more specific block and a new ROA
gets added to the repository for that]. Is there any case that's not
handled by doing this?
That's your _assumption_ of the sematics of a ROA. What reference material or
working group draft can you cite for semantic interpretation of a ROA?
draft-ieft-sidr-roa-validation? I don't think so. The point of hte BOA draft
it that it challenges this assumption by taking the position that such route
aorigination authorities are explicitly scoped to the authority described in
the object, without the implicit inclusion of any other authority or denial.
We are still in the process of specifying things and what they mean,
i.e., the drafts aren't done yet.
Actually, we are not arguing about the semantics of a single ROA as much
as we are arguing about the semantics of a set of ROAs.
If one ROA means "this AS is allowed to advertise this prefix", does the
complete set of ROAs mean "these ASs and maybe others are allowed to
advertise this prefix" or "these ASs and no others are allowed to
advertise this prefix".
Do prefix holders (who are RPKI aware) sign ROAs for every AS that might
announce their prefix?
If so, what does that mean about interpreting ROAs?
If not, what does that mean about interpreting ROAs?
AS referred to earlier, here's the list of today's bogon AS numbers, just in
case you thought that this is a non-problem:
<snip>
Wow. And the Internet still works. Amazing.
Given the general falibility of humans, I presume there are cases where
one AS gets its AS number wrong and uses some other (allocated) AS number?
Is that common? There are configuration options to check if your neighbor
AS is using the proper AS number in its advertisement to you - but since
it's an option, I'm guessing you can NOT check if you want.
What is the damage right now to using an unallocated AS? Mis-using an
allocated AS?
What would be the damage in an RPKI aware router from an announcement that
used an unallocated AS? (Would ROAs or prefix-BOAs prevent such
announcements?) What about an announcement that mis-used an allocated AS?
--Sandy
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
