Re: [Sidrops] New Version Notification for draft-sriram-sidrops-drop-invalid-policy-00.txt

Tim Bruijnzeels <tim@ripe.net> Mon, 12 March 2018 08:50 UTC

Return-Path: <tim@ripe.net>
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 A8E671241F5 for <sidrops@ietfa.amsl.com>; Mon, 12 Mar 2018 01:50:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 hTqdZKDoW33I for <sidrops@ietfa.amsl.com>; Mon, 12 Mar 2018 01:50:45 -0700 (PDT)
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 E857E12711D for <sidrops@ietf.org>; Mon, 12 Mar 2018 01:50:44 -0700 (PDT)
Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <tim@ripe.net>) id 1evJAH-0000VI-VZ; Mon, 12 Mar 2018 09:50:42 +0100
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-252.ripe.net) by nene.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <tim@ripe.net>) id 1evJAH-00035R-RR; Mon, 12 Mar 2018 09:50:41 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <20180311142500.GO98483@vurt.meerval.net>
Date: Mon, 12 Mar 2018 09:50:31 +0100
Cc: Geoff Huston <gih@apnic.net>, Randy Bush <randy@psg.com>, SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B5CE9C1D-58C6-48E8-B058-1036C1AB8CCA@ripe.net>
References: <152029076512.12908.14537578849320525718.idtracker@ietfa.amsl.com> <BYAPR09MB2773819AB3961189CDA9B4D784D90@BYAPR09MB2773.namprd09.prod.outlook.com> <074D75CB-7D34-4838-BEAA-88AE5E044F6C@ripe.net> <20180310120844.GC35705@vurt.meerval.net> <m237176zk6.wl-randy@psg.com> <20180311110042.GF98483@vurt.meerval.net> <06C08F03-6386-414C-B93E-EA3CADC9D996@apnic.net> <CACWOCC-ykSe4KLO=KK1e+DED_XPhuprGr7-x=6Rauiqa_njp7g@mail.gmail.com> <F393FC7A-A381-497A-A80B-015EA2508B20@apnic.net> <20180311142500.GO98483@vurt.meerval.net>
To: Job Snijders <job@ntt.net>
X-Mailer: Apple Mail (2.3445.5.20)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: -------
X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07198bca16526ae952332e3065aa8d8e9303
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/ahhz0Rvfo1zJN5FbUxr9XthJjS0>
Subject: Re: [Sidrops] New Version Notification for draft-sriram-sidrops-drop-invalid-policy-00.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 12 Mar 2018 08:50:47 -0000

Hi all,

I believe something like this will be needed in case a DISR policy is used. As currently written the draft leaves any unannounced space vulnerable to hijacking. The only way really to counter this would be for the address holder to issue a ROA for their AS and do the public announcement - as Job pointed out there are operational reasons why this may not be possible / very undesired.

With regards to BOAs - my memory may fail me here because part of the discussion was from before even my time on this, but I thought it was concluded that the same could be communicated with an AS0 ROA, so there was no need for an explicit object type.

That said, If I can entertain the thought of a BOA or AS0 (as the only) ROA for address space.. then the intention would certainly be that an address holder can indicate that some of their address space should not appear in the global BGP. Implementing this is not super trivial - it’s not just another ROA for an AS that happens to be one that cannot be naturally found. In particular someone could do an announcement for a large prefix (say a /16 or something) that is less specific than any ROA issued. It would get RPKI validation state ‘not found’ and any otherwise unannounced space would be routed here. For BOAs / AS0 ROAs to work here the semantics would have to be changed to something like: if *any* of the address space in a prefix is covered by a BOA / AS0 ROA *only* then consider it *invalid* — or *forbidden* even if we want to recognise this as a different flavour of invalid.

Kind regards,

Tim




> On 11 Mar 2018, at 15:25, Job Snijders <job@ntt.net> wrote:
> 
> On Sun, Mar 11, 2018 at 10:14:45AM -0400, Geoff Huston wrote:
>>> On 11 Mar 2018, at 9:24 am, Job Snijders <job@ntt.net> wrote:
>>> 
>>> On Sun, 11 Mar 2018 at 14:21, Geoff Huston <gih@apnic.net> wrote:
>>>> 
>>>> Perhaps what is lacking in the semantics of RPKI is a "kill roa”.
>>> 
>>> https://datatracker.ietf.org/doc/draft-huston-sidr-bogons/
>>> 
>>> What happened to that draft?
>> 
>> It was unceremoniously killed due to extreme distaste on the part of
>> various folk who represented themselves as members of the crypto
>> zealotry group. I also suspect that the authors’ efforts to use the
>> term “boa constrictor" at least once the draft was seen as a juvenile
>> attempt at humour. :-) I guess you just had to be there! 
>> 
>> More seriously, the draft encountered fatal levels of criticism over
>> the concept of this form of validated negation.
> 
> Given that ~ 10 years have passed, and there are now give or take 5
> autonomous systems doing Origin Validation, perhaps some of the folks
> involved back then would be willing to reconsider their opinion? :)
> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops