Re: [Sidrops] draft-sidrops-rpkimaxlen
Matthias Waehlisch <m.waehlisch@fu-berlin.de> Sun, 24 February 2019 00:46 UTC
Return-Path: <m.waehlisch@fu-berlin.de>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9399128D0B; Sat, 23 Feb 2019 16:46:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXaC2icSEz0L; Sat, 23 Feb 2019 16:46:12 -0800 (PST)
Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02CF1128701; Sat, 23 Feb 2019 16:46:12 -0800 (PST)
Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (envelope-from <m.waehlisch@fu-berlin.de>) id <1gxhvl-0042v5-9b>; Sun, 24 Feb 2019 01:46:09 +0100
Received: from x4dbf3522.dyn.telefonica.de ([77.191.53.34] helo=mw-x1.fritz.box) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from <m.waehlisch@fu-berlin.de>) id <1gxhvk-000mNN-VS>; Sun, 24 Feb 2019 01:46:09 +0100
Date: Sun, 24 Feb 2019 01:46:07 +0100
From: Matthias Waehlisch <m.waehlisch@fu-berlin.de>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
cc: "sidrops@ietf.org" <sidrops@ietf.org>, "draft-ietf-sidrops-rpkimaxlen@ietf.org" <draft-ietf-sidrops-rpkimaxlen@ietf.org>
In-Reply-To: <SN6PR0901MB236677B37676FFB11A22B14D84780@SN6PR0901MB2366.namprd09.prod.outlook.com>
Message-ID: <alpine.WNT.2.00.1902240047270.4012@mw-x1>
References: <SN6PR0901MB236677B37676FFB11A22B14D84780@SN6PR0901MB2366.namprd09.prod.outlook.com>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
X-X-Sender: waehl@mail.zedat.fu-berlin.de
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Originating-IP: 77.191.53.34
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/jEhqAzcedaFevmr1Bzmu6hxhWDI>
Subject: Re: [Sidrops] draft-sidrops-rpkimaxlen
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Feb 2019 00:46:15 -0000
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
- [Sidrops] draft-sidrops-rpkimaxlen Matthias Waehlisch
- Re: [Sidrops] draft-sidrops-rpkimaxlen Randy Bush
- Re: [Sidrops] draft-sidrops-rpkimaxlen Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] draft-sidrops-rpkimaxlen Matthias Waehlisch
- Re: [Sidrops] draft-sidrops-rpkimaxlen Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] draft-sidrops-rpkimaxlen Matthias Waehlisch
- Re: [Sidrops] draft-sidrops-rpkimaxlen Sriram, Kotikalapudi (Fed)
- Re: [Sidrops] draft-sidrops-rpkimaxlen Matthias Waehlisch
- Re: [Sidrops] draft-sidrops-rpkimaxlen Jakob Heitz (jheitz)
- Re: [Sidrops] draft-sidrops-rpkimaxlen Randy Bush
- Re: [Sidrops] draft-sidrops-rpkimaxlen Ben Maddison
- Re: [Sidrops] draft-sidrops-rpkimaxlen Di Ma
- Re: [Sidrops] draft-sidrops-rpkimaxlen George Michaelson
- Re: [Sidrops] draft-sidrops-rpkimaxlen Di Ma
- Re: [Sidrops] draft-sidrops-rpkimaxlen Christopher Morrow
- Re: [Sidrops] draft-sidrops-rpkimaxlen Ben Maddison
- Re: [Sidrops] draft-sidrops-rpkimaxlen Christopher Morrow