Re: [Sidrops] Block ROA creation for AS23456?

Job Snijders <job@ntt.net> Thu, 18 May 2017 12:45 UTC

Return-Path: <job@instituut.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 2E429129C71 for <sidrops@ietfa.amsl.com>; Thu, 18 May 2017 05:45:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] 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 YkIeMVJYpfWr for <sidrops@ietfa.amsl.com>; Thu, 18 May 2017 05:45:15 -0700 (PDT)
Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com [209.85.128.169]) (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 59D5712EAEC for <sidrops@ietf.org>; Thu, 18 May 2017 05:40:06 -0700 (PDT)
Received: by mail-wr0-f169.google.com with SMTP id l9so33070361wre.1 for <sidrops@ietf.org>; Thu, 18 May 2017 05:40:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=BOO3p4W3WjYAkCuuNj3WrgLuGJPd9461ukWMPfBeCCQ=; b=kjF3UsPZMmIBybpfJ1JKac+vVVIhUpZwL071Bo8wBtPa8hDhbZ9VIA3T72OJnUIA1H 1L86VK+uBzCh1ahrr87VMSJzxVLePxqKzEbiX8arvWGPTbTzB/JttEM6xc85QesoiItW 6etyNj47v2UVSKVqeHS7HXGeaP2CZQsi6vypigbBL8CcT/U1xfcXKqaTxfdHxeVBX1Ia O79eLGrlAS3Eyx1is+104u3H9M03gRDuQGW/C0TGaSdZsNZfn2U52lTJxPaV2Gu7ylIh 3psIm1ySrWM2deOUh/6xUw+QyuQJdCTCXtr9fGNvRcInDsIw71extlIYjyUcncOyQ7ht wr3Q==
X-Gm-Message-State: AODbwcCdaZPnnAyX54jZg7CFOfi4T5WOBg3yWMv4CucCMG2k/FCykM4V eqZL8iBMROIqkpKcarCKsA==
X-Received: by 10.80.148.194 with SMTP id t2mr3148440eda.128.1495111204633; Thu, 18 May 2017 05:40:04 -0700 (PDT)
Received: from localhost ([89.200.40.67]) by smtp.gmail.com with ESMTPSA id m9sm2574346edm.62.2017.05.18.05.40.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2017 05:40:03 -0700 (PDT)
Date: Thu, 18 May 2017 14:39:59 +0200
From: Job Snijders <job@ntt.net>
To: Alex Band <alexb@ripe.net>
Cc: sidrops@ietf.org
Message-ID: <20170518123959.clizw3w7sp7hrplk@Vurt.local>
References: <m2o9uq4jb6.wl-randy@psg.com> <9C01478A-B764-48C4-AB93-4DEACB229A09@ripe.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9C01478A-B764-48C4-AB93-4DEACB229A09@ripe.net>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170306 (1.8.0)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/hkSZzgemIxbcpTbukx_EJ__5lv4>
Subject: Re: [Sidrops] Block ROA creation for AS23456?
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <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: Thu, 18 May 2017 12:45:18 -0000

On Thu, May 18, 2017 at 01:36:45PM +0200, Alex Band wrote:
> One of our members argues that we should be preventing that ROAs are
> created which authorise AS23456, as referred to in RFC6793 [1]. It
> would allegedly open up possibilities for abuse. You could make the
> same argument for several other special registry AS Numbers [2]. 

One probably has to carefully assess per 'special ASN' whether it makes
sense or not. Preventing that ROAs are created with AS0 would be counter
productive in some scenarios.

> I’m curious to hear if you think this argument holds any truth, and if
> we should be thinking about such measures.

Did the member elaborate on what problem the restriction would resolve?
I'd be interested to learn more about the possibilities for abuse.

Kind regards,

Job