From nobody Wed Feb 8 06:25:47 2017 Return-Path: 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 D3A6A129B1A for ; Wed, 8 Feb 2017 06:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 fQ0JI5BebKnC for ; Wed, 8 Feb 2017 06:25:42 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 3149A1293E0 for ; Wed, 8 Feb 2017 06:25:42 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cbTBj-0003GH-ID; Wed, 08 Feb 2017 15:25:40 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-181.ripe.net) by nene.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1cbTBj-0006sd-B3; Wed, 08 Feb 2017 15:25:39 +0100 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: <20170113185851.GD1055@Vurt.local> Date: Wed, 8 Feb 2017 15:25:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161108161154.GV37681@Vurt.lan> <7C119394-504F-478E-8A16-D4C59159B619@ripe.net> <20170113185851.GD1055@Vurt.local> To: Job Snijders X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: --------- X-RIPE-Spam-Report: Spam Total Points: -9.4 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0014] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719053c6b668018a25c4d3fdaee169a356d Archived-At: Cc: sidrops@ietf.org Subject: Re: [Sidrops] MaxLength Considered Harmful to the RPKI? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 14:25:44 -0000 Hi, > On 13 Jan 2017, at 19:58, Job Snijders wrote: >=20 > On Thu, Nov 17, 2016 at 02:01:50PM +0900, Tim Bruijnzeels wrote: >> First of all: good read. And I actually agree that the MaxLength >> attribute should be eliminated. >=20 > So how do we go about that? Not sure.. but thinking more about this again I am inclined to look at = this as a best practices or operational problem. Just because the ROA = specification allows the use of 'max length' as a 'macro' so that one = doesn't have to create many different ROAs, doesn't mean that one = SHOULD.. And reading RFC7115 "RPKI-Based Origin Validation Op" again, there is = already fairly strong advice against the over-use of max length. = Specifically it has this: One advantage of minimal ROA length is that the forged origin attack does not work for sub-prefixes that are not covered by overly long max length. For example, if, instead of 10.0.0.0/16-24, one issues 10.0.0.0/16 and 10.0.42.0/24, a forged origin attack cannot succeed against 10.0.666.0/24. They must attack the whole /16, which is more likely to be noticed because of its size. I think it would be worth discussing in sidr-ops whether this is enough = warning or more is needed. Practically speaking as an implementer of RPKI as a service to RIPE NCC = members, I would be happy to take out the option of using a max length = in our interface if there is strong advice against its use. FWIW we have = had people asking about a use case where they 'sometimes' need to do = more specific announcements and therefore they were thinking of using a = wildcard 'maxlength', but after discussion they have decided to use the = API that we have for our (hosted) service instead - so they can automate = issuing more specific ROAs when needed. Tim >=20 > Kind regards, >=20 > Job >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Feb 8 11:05:19 2017 Return-Path: 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 432B4129D9C for ; Wed, 8 Feb 2017 11:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 U_c61eHHdAK0 for ; Wed, 8 Feb 2017 11:05:17 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799AC129DA6 for ; Wed, 8 Feb 2017 11:05:03 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cbXY5-0001ND-L4; Wed, 08 Feb 2017 19:05:01 +0000 Date: Thu, 09 Feb 2017 04:05:00 +0900 Message-ID: From: Randy Bush To: Tim Bruijnzeels In-Reply-To: References: <20161108161154.GV37681@Vurt.lan> <7C119394-504F-478E-8A16-D4C59159B619@ripe.net> <20170113185851.GD1055@Vurt.local> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidrops@ietf.org Subject: Re: [Sidrops] MaxLength Considered Harmful to the RPKI? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 19:05:18 -0000 > thinking more about this again I am inclined to look at this as a best > practices or operational problem. Just because the ROA specification > allows the use of 'max length' as a 'macro' so that one doesn't have > to create many different ROAs, doesn't mean that one SHOULD.. > > And reading RFC7115 "RPKI-Based Origin Validation Op" again, there is > already fairly strong advice against the over-use of max > length. Specifically it has this: > > One advantage of minimal ROA length is that the forged origin attack > does not work for sub-prefixes that are not covered by overly long > max length. For example, if, instead of 10.0.0.0/16-24, one issues > 10.0.0.0/16 and 10.0.42.0/24, a forged origin attack cannot succeed > against 10.0.666.0/24. They must attack the whole /16, which is more > likely to be noticed because of its size. > > I think it would be worth discussing in sidr-ops whether this is > enough warning or more is needed. wfm