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

[Geoff Huston <[e-mail]>]

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
[e-mail]
https://www.ietf.org/mailman/listinfo/sidr