Re: [Sidrops] draft-sidrops-rpkimaxlen

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

Hi Matthias,

-- snip --
>> The draft does not presuppose when the prefixes may need to be 
>> announced. The time frame is up to the prefix owner. Once the prefix 
>> owner decides what prefixes (currently announced or intended to be 
>> announced) should be covered by the ROA (or ROAs), the draft merely 
>> offers recommendations for minimizing the attack surface. The example 
>> in Section 5.1 illustrates this for the DDoS case. (One more example 
>> can be added there to further drive home the point.) The example is 
>> agnostic about if/when the DDoS mitigation prefixes may need to be 
>> announced.
>> 
>  sorry but I really don't see how this limits the attack surface, in 
>case where the configured more specific prefix is announced very 
>occasionally.

We know that with fully deployed BGPsec (if ever), there is no concern about 
forged-origin attacks and no concern for ROAs created for DDoS mitigation.
But in the absence of BGPsec, there are two options as follow:

1. Pre-create ROAs for the DDoS mitigation service and 
minimize the attack surface per draft. 

For example, customer announces 168.122.0.0/16 and associated /17s,
also announces 168.122.32.0/24 (for TE), and   
and contracted DDoS mitigation service for 168.122.5.0/24.
Their servers are located in 168.122.5.0/24. 
The draft recommends the customer should create ROAs as follows:
ROA: {168.122.0.0/16, maxlength = 17}, 168.122.32.0/24, AS 64496
ROA: 168.122.5.0/24, AS 64500      
Note: AS 64500 is the DDoS mitigation SP

For this example, the draft warns against creating these kinds of ROAs 
which would have unnecessarily large attack surface:
ROA: 168.122.0.0/16, maxlength = 24, AS 64496
ROA: 168.122.0.0/16, maxlength = 24, AS 64500 
  
2. Create ROAs for DDoS mitigation on demand. Then, the risk is that there 
may be long RPKI/ROA propagation delays and the DDoS mitigation 
response time suffers. (May be the RIRs and ISPs can be persuaded to 
invest to cut this delay down.)

There are trade-offs associated with the two methods.
If you have other suggestions, we would like to hear. 

-- snip --  
>> I read the DECIX wiki page.  It is not clear to me what you mean by 
>> incorrect conclusions on that page with regard to ROA/maxlength . I 
>> would appreciate if you can clarify or cite some examples.
>> 
>  To give one example: Your draft suggests to not use the max length 
>field, which means "ROA generation software MUST use the prefix length 
>as the max length if the user does not specify a max length." [RFC 7115]

No, the draft that does not intend to suggest “never use maxlength”.
I have clarified this before, and you replied, “I got this”.
Also, see the example above which includes judicious use of maxlength. 
  
>  Option 3 in the wiki page, they will set the max length to the max 
>length of the IP version (e.g., /32 for v4). This is different to your 
>proposal.

Yep, this is not relevant to the draft. The DECIX effort is about how 
the IXP can validate Blackhole messages from customers.

>
>  Based on what you wrote, each member that intends to send a 
>blackholing announcement would need to create a corresponding ROA. 
>Option 3, actually, tries to solve the problem when members forget to do 
>this.

This again has really nothing to do with the draft’s recommendations. 
The draft doesn’t even mention ROAs with  > /24 IPv4 and > /48 IPv6.
In general, I would say, IXP/ISP should not require ROAs for the 
more specific Blackhole prefixes. They can be loosely validated without
requiring ROAs (for those more specific prefixes) 
as DECIX seems to be doing (option 3). 

We can chat about all this some more in Prague.

I will speak with my co-authors about making the draft a bit more general
per your suggestion.

Thanks.

Regards,
Sriram