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

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
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr