Re: [Sidrops] draft-sidrops-rpkimaxlen

[Matthias Waehlisch <[e-mail]>]

Hi Sriram,

On Sat, 23 Feb 2019, Sriram, Kotikalapudi (Fed) wrote:

> >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   
> 
  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.
> 
> 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.
> 
  I got this, see below.

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

>    "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).
>
  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).
> 
> 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'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