Re: [Sidrops] draft-sidrops-rpkimaxlen

[Matthias Waehlisch <[e-mail]>]

Hi Sriram,

On Mon, 25 Feb 2019, Sriram, Kotikalapudi (Fed) wrote:

> -- 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
> 
  I'm not sure whether this "minimizes" the attack surface.

  Minimizing probably means that you create the ROAs on demand.

> 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
>   
  Btw, this warning is already noted in RFC 7115.

> 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. 
> 
  No other suggestions. My original point was that the draft is 
misleading because the draft highlights the max length field.

> -- 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”.
>
  I was not writing "never" ;). Sorry that the text gave the impression.


> We can chat about all this some more in Prague.
> 
  Will be there.



Thanks
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl