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

["Pradosh Mohapatra (pmohapat)" <[e-mail]>]

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? 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? 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?


| >> 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?

- Pradosh
_______________________________________________
sidr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sidr