Subject: Re: [Sidrops] draft-sidrops-rpkimaxlen

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Sat, 23 Feb 2019 22:04:07 +0000

Hi Matthias,

>I read the (expired) draft draft-sidrops-rpkimaxlen.

It appears that a fork in the draft stream occurred inadvertently 
sometime ago when Job tried to upload a new version. 
You were looking at the "expired" branch. 
The draft is active:
https://tools.ietf.org/html/draft-ietf-sidrops-rpkimaxlen-01   

>The problem analysis in the draft is misleading.
>The problem is not the usage of the max length field. Even without a
>max length field, a "forged-origin subprefix hijack" may occur easily. 
>For example, a minimal, more specific ROA has been created, and the 
>prefix is currently not announced by the origin AS configured in the ROA.

IMO, the spirit and intention of the document is in complete alignment 
with what you are trying to covey. It is the *misuse* of maxlength that 
the draft cautions about. Adding the following wording (with some 
further refinement) in the document will help clarify:

A minimal ROA is one which includes prefixes that are currently 
announced or are intended to be announced. Use of maxlength 
can be avoided or it should be used judiciously so that 
more specific prefixes that are not intended to be announced 
are not covered by the ROA. The idea is to minimize the attack
surface corresponding to forged-origin subprefix hijacking.     

>The draft implicitly suggests: "Only create ROAs for prefixes that are 
>currently announced." I'm not sure whether the WG has consensus about 
>that.

This was not the intent in the draft. A better definition of minimal ROA as
outlined above will take care of the misunderstanding. 
The draft did recognize that the IP prefixes planned to be announced 
in the future or intermittently (when needed) may be included in the ROA.
Please see the following paragraph from Section 5.1:  

   "In this case, the ROA SHOULD include (1) the set of IP prefixes that
   are always originated in BGP, and (2) the set IP prefixes that are
   sometimes, but not always, originated in BGP.  The ROA SHOULD NOT
   include any IP prefixes that the operator knows will not be
   originated in BGP."

There is a use case described after that involving DDoS mitigation.

>The draft is expired. I suggest to leave it expired because it leads 
>to incorrect conclusions, see for example 
>https://github.com/DECIX/RPKI/wiki/RPKI-deployment-options 

I carefully went through the link you've provided. Nice work!
I do not see any inconsistency between your approach with ROAs 
and what is in the draft, especially with the better definition of ROA as
stated above (IMO). Please let us know if you still see it differently.
In fact, there is a similarity between your Blackhole use case
and the DDoS mitigation use case in the draft (except that 
the latter doesn't involve prefixes more specific than /24 IPv4  or /48 IPv6).

DDoS mitigation providers' needs are discussed in Section 5.1 
and network operators seem to have found that discussion and 
related recommendations quite useful. Please see this thread: 

https://lists.arin.net/pipermail/arin-tech-discuss/2018-August/000723.html   

It should be noted that the document is aimed to be a BCP, not standards track.

Thanks for your inputs.

Regards,
Sriram

---

From: Matthias Waehlisch <[email-masked]>
Date: Sun, 24 Feb 2019 01:46:07 +0100

Hi Sriram,

> https://tools.ietf.org/html/draft-ietf-sidrops-rpkimaxlen-01   
  hmm, strange. Anyhow, the diff between the 00 and the 01 version 
relates only to the version number and date. My previous email is still 
valid, except that the draft is unfortunately not expired.

> >The problem analysis in the draft is misleading. The problem is not 
> >the usage of the max length field. Even without a max length field, a 
> >"forged-origin subprefix hijack" may occur easily. For example, a 
> >minimal, more specific ROA has been created, and the prefix is 
> >currently not announced by the origin AS configured in the ROA.
> 
> with what you are trying to covey. It is the *misuse* of maxlength 
> that the draft cautions about. Adding the following wording (with some 
> announced or are intended to be announced. Use of maxlength can be 
> avoided or it should be used judiciously so that more specific 
> prefixes that are not intended to be announced are not covered by the 
> ROA. The idea is to minimize the attack surface corresponding to 
> forged-origin subprefix hijacking.
> 
  I got this, see below.

> This was not the intent in the draft. 
>
  It was, as you wrote: "A minimal ROA is one which includes prefixes 
that are currently announced or are intended to be announced."

> A better definition of minimal ROA as outlined above will take care of 
> the misunderstanding. The draft did recognize that the IP prefixes 
> planned to be announced in the future or intermittently (when needed) 
> may be included in the ROA. Please see the following paragraph from 
> Section 5.1:
> 
  This is not very helpful. "when needed" is fuzzy. Needed in six month? 
Do you know when a DDoS occurs? The draft supposes that needed is very 
short-term.

> I carefully went through the link you've provided. Nice work! I do not 
> see any inconsistency between your approach with ROAs and what is in 
> the draft, especially with the better definition of ROA as stated 
> above (IMO).
>
  Just to be clear: I was neither writing nor giving input to the wiki 
page.

  What I tried to say is that the authors of the wiki page draw 
incorrect conclusions, probably based on misleading insights from the 
draft.

> Please let us know if you still see it differently. In fact, there is 
> a similarity between your Blackhole use case and the DDoS mitigation 
> use case in the draft (except that the latter doesn't involve prefixes 
> more specific than /24 IPv4 or /48 IPv6).
> 
  "It's also worth noting that pre-publishing many ROAs for 
not-normally-announced prefixes in the way Andrew was asking about 
creates the same exposure as would be caused by [mis]using max length." 
-- I agree on this.

> It should be noted that the document is aimed to be a BCP, not standards track.
  Yes, but again, the draft articulates a wrong perspective. The problem 
is not about the max length field. The discussion about the max length 
field is a _corollary_ of the discussion that you suggest to not create 
ROAs for prefixes that are not announced or will not be announced in the 
very near future. ... max length is syntax.

  So, if you want to continue with this topic, I suggest to write a more 
general draft. I'm not sure whether it is helpful, though, because there 
are use cases where we cannot say when the announcement will be active.

Cheers
  matthias

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

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Sun, 24 Feb 2019 03:43:16 +0000

Hi Matthias,

>> forged-origin subprefix hijacking.

OK. Good.

--- snip ----

>Do you know when a DDoS occurs? The draft supposes that needed is very

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.    

--- snip ----

>incorrect conclusions, probably based on misleading insights from the

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.

Thanks.  

Sriram

---

From: Matthias Waehlisch <[email-masked]>
Date: Sun, 24 Feb 2019 14:50:21 +0100

Hi Sriram,

On Sun, 24 Feb 2019, Sriram, Kotikalapudi (Fed) wrote:

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

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

  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.

  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.

Cheers
  matthias

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Mon, 25 Feb 2019 03:10:12 +0000

Hi Matthias,

-- snip --
>case where the configured more specific prefix is announced very 

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 --  
>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. 
  
>length of the IP version (e.g., /32 for v4). This is different to your 

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

>Option 3, actually, tries to solve the problem when members forget to do 

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

---

From: Matthias Waehlisch <[email-masked]>
Date: Mon, 25 Feb 2019 11:15:22 +0100

Hi Sriram,

> forged-origin attacks and no concern for ROAs created for DDoS mitigation.
  ;).

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

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

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

> 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