From nobody Tue Nov 8 08:12:05 2016 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 69725129977 for ; Tue, 8 Nov 2016 08:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] 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 lPM27quMqNFh for ; Tue, 8 Nov 2016 08:12:02 -0800 (PST) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 4069A1299A6 for ; Tue, 8 Nov 2016 08:12:02 -0800 (PST) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c490C-000G9u-EB (job@us.ntt.net); Tue, 08 Nov 2016 16:12:02 +0000 Date: Tue, 8 Nov 2016 17:11:54 +0100 From: Job Snijders To: sidrops@ietf.org Message-ID: <20161108161154.GV37681@Vurt.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Subject: [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: Tue, 08 Nov 2016 16:12:04 -0000 Hi group, I stumbled across a interesting publication called "MaxLength Considered Harmful to the RPKI" which raised questions. Given that we don't have path validation, and origins are easily spoofed, this is a relevant operational consideration. You can download the paper here: https://eprint.iacr.org/2016/1015.pdf Cutting to the chase: in chapter 7 the authors put forward: "We therefore suggest eliminating the maxLength attribute..." (followed by some alternative ideas). I took the suggestion and deployed according routing policy in AS 8283 - a BGP playground in Amsterdam. At first I was dropping all non-exact ROA matching routes, but quickly had to revert to just BGP Community tagging. IPv4: as8283-router$ birdc 'show route where (8283,100) ~ bgp_community primary' | wc -l 21300 (3.5% of the IPv4 routes in the Default-Free Zone) IPv6: as8283-router$ birdc6 'show route where (8283,100) ~ bgp_community primary' | wc -l 1261 (3.7% of the IPv6 routes in the Default-Free Zone) I wrote this small proof-of-concept tool to take RPKI data and convert it into a static configs so I can easily toy with different ideas in a real world deployment: https://github.com/job/rtrsub So today, November 2016, flat out ignoring MaxLength will break your connectivity, but MaxLength can't be fully trusted either. Thoughts? Kind regards, Job From nobody Tue Nov 8 08:16:55 2016 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 213FA1298BA for ; Tue, 8 Nov 2016 08:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Vk0IriLCCtit for ; Tue, 8 Nov 2016 08:16:51 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 75E131294A3 for ; Tue, 8 Nov 2016 08:16:51 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id n21so111726905qka.3 for ; Tue, 08 Nov 2016 08:16:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=7Kmme87G9M9TrKCONb/ESNK8OsvnXyiYLuELGWuPQN8=; b=C5ZDnJ03iM0xq0+Csvjd0NgQt1wTVQ3gbxOBbWFLWGcUAdtGZOUdU9GFzD3qeP0Oc9 vir/0MtYk2r5LJohN1R+gZlWmRRyhkETKuSmjR2d0GRgxPjmvEwAfI0QeTxzhZdAvjq3 eVAws0zqKHSJUPrLyC6aEr6bU+aWe51Jo1fWoMaM1SRPz/LcY9DLZ/Jtqh2QT0oprO3Z CKdsXP4hUJ9OdwdC1xazhk0DHLt7G/6yvVEIKEQLDpz5KbP1a7u4W2KXDmoAYUjYsoa1 CbulDmM/GXiG/TxjWD+iJSZFNUVbt/UXUg2HPSU6wDtp2AbP4gAMq0zHVbd5Y5zqkSYP MrRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=7Kmme87G9M9TrKCONb/ESNK8OsvnXyiYLuELGWuPQN8=; b=NE9gbPxfbru1BT/joupJz8OLsVhqq6WYDOwdy90nLnFEtPBsUpbKvDyGc5qQBbv78d CGxwXCjNy2m8q8o4sRiB9RDtSbphOB9OFYP8mba1uXub9p75U0eMmQ/0lMdcgKQKhaKK 2LOOFp93tkRpWifHRu97KxK3kLTedslAlPQVsM2drxh992xjc+mT5JC/+t63Lc0Ni0nD PH27uowvQ+LQKC6nMoOFrcEQ6MzhBcXkvhpUd0uLWZU1RjqLYqhwc/NWLU4LHp4Mmf5s 7LJpMmBzZGglnKRspRzTC6slQNbscKnqYG0qscD3JcYKetwBTb6kuBe9clI4FUws9V9V AnDQ== X-Gm-Message-State: ABUngvdgA040sDQo0BMXkMvIJuAJjxh7wmM0PTPmlVWaFIFC6CeNaSfBnkZ0MIPeS7MmzA== X-Received: by 10.233.232.200 with SMTP id a191mr14999282qkg.208.1478621810385; Tue, 08 Nov 2016 08:16:50 -0800 (PST) Received: from [200.7.87.47] ([2001:13c7:7001:7000:4450:9486:4f8a:bff]) by smtp.gmail.com with ESMTPSA id d81sm19785694qke.15.2016.11.08.08.16.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Nov 2016 08:16:49 -0800 (PST) From: "Carlos M. Martinez" To: "Job Snijders" Date: Tue, 08 Nov 2016 13:16:46 -0300 Message-ID: <5E1991D4-102E-46CD-9B34-A339FF380292@gmail.com> In-Reply-To: <20161108161154.GV37681@Vurt.lan> References: <20161108161154.GV37681@Vurt.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.5r5263) 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: Tue, 08 Nov 2016 16:16:54 -0000 Thanks Job, I’ll go through the publication. As anecdotal evidence, many of our training attendees find maxLen quite confusing, for some reason (I don’t have a proper explanation). In fact, many end up doing maxLen=32 (ipv4 of course) for everything. -Carlos On 8 Nov 2016, at 13:11, Job Snijders wrote: > Hi group, > > I stumbled across a interesting publication called "MaxLength > Considered > Harmful to the RPKI" which raised questions. Given that we don't have > path validation, and origins are easily spoofed, this is a relevant > operational consideration. > > You can download the paper here: https://eprint.iacr.org/2016/1015.pdf > > Cutting to the chase: in chapter 7 the authors put forward: "We > therefore suggest eliminating the maxLength attribute..." (followed by > some alternative ideas). > > I took the suggestion and deployed according routing policy in AS 8283 > - > a BGP playground in Amsterdam. At first I was dropping all non-exact > ROA > matching routes, but quickly had to revert to just BGP Community > tagging. > > IPv4: > as8283-router$ birdc 'show route where (8283,100) ~ bgp_community > primary' | wc -l > 21300 > (3.5% of the IPv4 routes in the Default-Free Zone) > > IPv6: > as8283-router$ birdc6 'show route where (8283,100) ~ bgp_community > primary' | wc -l > 1261 > (3.7% of the IPv6 routes in the Default-Free Zone) > > I wrote this small proof-of-concept tool to take RPKI data and convert > it into a static configs so I can easily toy with different ideas in a > real world deployment: https://github.com/job/rtrsub > > So today, November 2016, flat out ignoring MaxLength will break your > connectivity, but MaxLength can't be fully trusted either. > > Thoughts? > > Kind regards, > > Job > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Nov 16 21:02:03 2016 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 1363E129575 for ; Wed, 16 Nov 2016 21:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 NCiaURBevVog for ; Wed, 16 Nov 2016 21:02:00 -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 0B701129886 for ; Wed, 16 Nov 2016 21:02:00 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c7Eph-000CW5-7A; Thu, 17 Nov 2016 06:01:58 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-47.ripe.net) by titi.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1c7Epf-0002fi-OS; Thu, 17 Nov 2016 06:01:57 +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: <20161108161154.GV37681@Vurt.lan> Date: Thu, 17 Nov 2016 14:01:50 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <7C119394-504F-478E-8A16-D4C59159B619@ripe.net> References: <20161108161154.GV37681@Vurt.lan> 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: -10.4 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.9 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 BAYES_40 BODY: Bayes spam probability is 20 to 40% [score: 0.3283] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719078e4942c15e17bf2a99529e993bebad 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: Thu, 17 Nov 2016 05:02:02 -0000 Hi Job, First of all: good read. And I actually agree that the MaxLength = attribute should be eliminated. As the document explains authorising more specific announcements that = you do NOT do, makes it easy for attackers to spoof your ASN and do the = more specific announcement. Therefore you should NOT authorise these = gratuitously, and "Relying Parties" should treat more specific as = invalid in their routers. That way the attack is limited to spoofing = your AS and *matching* your announcement, this is not a full solution of = course but it's a much better place since such attacks are much less = effective. Going further: sometimes I hear people say that origin = validation without path validation is pointless, but I think this shows = that there is incremental value in origin validation alone (on top of = protecting against mistakes where the ASN is not spoofed). So in short: you should only authorise your actual announcements, and I = would support an update to the spec to get rid of MaxLength. Operational experience shows that MaxLength is highly confusing to = users, and it doesn't improve usability in significant ways. For what it's worth in our RPKI deployment we allow setting MaxLength = since it's in the spec, but we do not encourage it. In fact we just = encourage users to authorise the BGP announcements that they actually = want to do. We help our users by showing them the announcements that we = see in BGP, but of course users are free to add additional = authorisations for back-up routes, or planned announcements that we do = not see, *and* of course users can also choose to *not* authorise = announcements that they believe should be invalid. If we see an announcement that is invalid because of maxlength we offer = two options: first (default) create an authorisation for just this = additional announcement, or indeed modify MaxLength. I don't have access = to this right now because I am travelling, but I can get some statistics = on what our users do over the next weeks and report that. The original intent of MaxLength was for this to be a short-hand so that = in a case like: you have a IPv4 /20 and you do announce all the /24s, = you can set MaxLength so that you can have 1 ROA instead of 16. But.. I = really don't think this is a strong use case. If you really want all 16 = ROAs, you can create them individually (or script that). The other use case that we have encountered for MaxLength is cases where = holders of a bigger prefix do more specific announcements from time to = time. And they do not want to go into the UI every time and change = things manually. We defer these users to using our API instead. I.e. you = can modify your network management tools to automatically create the = authorisations as soon as do more specific announcements. Cheers Tim > On 09 Nov 2016, at 01:11, Job Snijders wrote: >=20 > Hi group, >=20 > I stumbled across a interesting publication called "MaxLength = Considered > Harmful to the RPKI" which raised questions. Given that we don't have > path validation, and origins are easily spoofed, this is a relevant > operational consideration. >=20 > You can download the paper here: https://eprint.iacr.org/2016/1015.pdf >=20 > Cutting to the chase: in chapter 7 the authors put forward: "We > therefore suggest eliminating the maxLength attribute..." (followed by > some alternative ideas). >=20 > I took the suggestion and deployed according routing policy in AS 8283 = - > a BGP playground in Amsterdam. At first I was dropping all non-exact = ROA > matching routes, but quickly had to revert to just BGP Community > tagging. >=20 > IPv4: > as8283-router$ birdc 'show route where (8283,100) ~ = bgp_community primary' | wc -l > 21300 > (3.5% of the IPv4 routes in the Default-Free Zone) >=20 > IPv6: > as8283-router$ birdc6 'show route where (8283,100) ~ = bgp_community primary' | wc -l > 1261 > (3.7% of the IPv6 routes in the Default-Free Zone) >=20 > I wrote this small proof-of-concept tool to take RPKI data and convert > it into a static configs so I can easily toy with different ideas in a > real world deployment: https://github.com/job/rtrsub >=20 > So today, November 2016, flat out ignoring MaxLength will break your > connectivity, but MaxLength can't be fully trusted either. >=20 > Thoughts? >=20 > Kind regards, >=20 > Job >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops