IETF Logo Mail Archive

Re: [Sidrops] Block ROA creation for AS23456?

Yang Yu <yang.yu.list@gmail.com> Thu, 18 May 2017 18:33 UTC

Return-Path: <yang.yu.list@gmail.com>
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 8FAAF129C21 for <sidrops@ietfa.amsl.com>; Thu, 18 May 2017 11:33:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 Dl7KOrGQ8czc for <sidrops@ietfa.amsl.com>; Thu, 18 May 2017 11:33:45 -0700 (PDT)
Received: from mail-oi0-x242.google.com (mail-oi0-x242.google.com [IPv6:2607:f8b0:4003:c06::242]) (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 3526D129B2F for <sidrops@ietf.org>; Thu, 18 May 2017 11:28:43 -0700 (PDT)
Received: by mail-oi0-x242.google.com with SMTP id w138so8763169oiw.3 for <sidrops@ietf.org>; Thu, 18 May 2017 11:28:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cksVqn1nrXJZBJHofdbfKyfYCYUEdaUwFVhKqBuqY3s=; b=DgFGx943MX0j4MlNFYAIFlNfqcOgJMTiiYy/+BacGElILu2S1/OANCa0Mj6y7DqQxm Fd+CmHV5OfyhppPrBxpNGQzTNqa7QW3o2QgpTCMqURjvuykDmXOGBcYrcMNiFvXdXGDY bDwL35uHWbX196iHyMC0Vp0Qa6QAPCKkj/A909Xu7xIjZSRPtobNc6f3e3AjRicXI+Iw 8VV/zJdggLOyOFdrGRIrJuSRiG7ux0yoTkzuun1M1j4i5I1zrDntPZZk/LTKvGnz9GUd Uybk+8F2GqJW5DSWPis6D3v5c3sEb93uZ4VtZGXiWvbe9RAz4+RDgfP8IqUAJZiE1zs5 eB+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:cc:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=cksVqn1nrXJZBJHofdbfKyfYCYUEdaUwFVhKqBuqY3s=; b=s7/xipYOSG/bflYPTEzOedxZyqq/Fik8+oihxzE8DipTvL8+PgaIp3l0mQVVtm90U0 qVeY3rqyH8tqUjZS/5k8Q5kxpv2Mh/8BuQSUJDs8hkyZZf9KKxIikS6sQqKiwRj2qOM0 pFahvmmxbsp2aW/VdFZJ12X3QdX90ekmCLwHnkECEyp+G3eGEkZK4mkS5qA/SA1Y5mtb ZNvV/5PyyynsEsVRnZZCmfrRNI45tGbWQbtZHgjx45vOl1FYylVUSDvro80vOcmHbals +9qVzJpLVw6675UTfZKPmHAilSvGs/FsKGKVCZNaPVDqGIWfBLJUBzgYe+Q/dK8h9w2Z mB3w==
X-Gm-Message-State: AODbwcAKQZbZLnSlADJ+KPpK+jWfynIyyGpgva3fUXvmpThKYBTMUeis yeec/HKd4qc58A==
X-Received: by 10.157.7.130 with SMTP id 2mr2751592oto.99.1495132122612; Thu, 18 May 2017 11:28:42 -0700 (PDT)
Received: from ?IPv6:2605:6000:8cc6:4381:8d1b:7d71:c5ed:54be? ([2605:6000:8cc6:4381:8d1b:7d71:c5ed:54be]) by smtp.gmail.com with ESMTPSA id 14sm2929404oib.11.2017.05.18.11.28.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2017 11:28:42 -0700 (PDT)
Reply-To: yang.yu.list@gmail.com
To: "Carlos M. Martinez" <carlosm3011@gmail.com>, Roque Gagliano <rogaglia@cisco.com>
Cc: Alex Band <alexb@ripe.net>, "sidrops@ietf.org" <sidrops@ietf.org>
References: <m2o9uq4jb6.wl-randy@psg.com> <9C01478A-B764-48C4-AB93-4DEACB229A09@ripe.net> <06d5677bff924ad0b23e56c685369fc1@XCH-RTP-011.cisco.com> <E0567D84-4C4D-4D15-BBE4-2124155BC791@ripe.net> <C083CBCB-3FB5-4934-9BA0-22F02D15016D@cisco.com> <4CB56A31-0242-4F2B-89C0-F216571E815E@gmail.com>
From: Yang Yu <yang.yu.list@gmail.com>
Message-ID: <4a81aa22-b76b-4455-8576-ad666491fec3@gmail.com>
Date: Thu, 18 May 2017 13:28:38 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <4CB56A31-0242-4F2B-89C0-F216571E815E@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/QF1a899iUXh-LGhONb0trXY6Bn4>
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 18:50:06 -0000

Is there a legitimate use of AS23456 ROA?

 >rfc7115 section 6
Routers that perform RPKI-based origin validation must support Four- 
octet AS Numbers (see [RFC6793]), as, among other things, it is not 
reasonable to generate ROAs for AS 23456.


Yang


On 05/18/2017 08:51 AM, Carlos M. Martinez wrote:
> Indeed. This should be an RP’s call to make IMO.
> 
> On 18 May 2017, at 9:51, Roque Gagliano (rogaglia) wrote:
> 
>> Hi,
>>
>> I would be more inclined to let the RP to solve it. Maybe with a 
>> switch to “ignore-roas-with-reserved-asn-other-than-0” and let that to 
>> be a SP decision to turn it ON/OFF with maybe the default to be to 
>> ignore them.
>>
>> Regards,
>> Roque
>>
>>
>>
>> —
>> Roque Gagliano
>> Tail-f Solutions Architect Southern Europe
>> +41 76 449 8867
>>
>>
>> On 18/05/17 14:31, "Alex Band" <alexb@ripe.net> wrote:
>>
>>     Hi Roque,
>>
>>     We’re only talking about actively preventing creation of the ROA 
>> under the CA.
>>
>>     Cheers,
>>
>>     Alex
>>
>>
>>     > On 18 May 2017, at 14:25, Roque Gagliano (rogaglia) 
>> <rogaglia@cisco.com> wrote:
>>     >
>>     > Hi Alex,
>>     >
>>     > Are we talking about the CA should prevent creation and/or the 
>> RP should ignore it when validating?
>>     >
>>     > Roque
>>     >
>>     > ----- Reply message -----
>>     > From: "Alex Band" <alexb@ripe.net>
>>     > To: "sidrops@ietf.org" <sidrops@ietf.org>
>>     > Subject: [Sidrops] Block ROA creation for AS23456?
>>     > Date: Thu, May 18, 2017 13:42
>>     >
>>     > Hello SidrOps folks,
>>     >
>>     > 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].
>>     >
>>     > I’m curious to hear if you think this argument holds any truth, 
>> and if we should be thinking about such measures.
>>     >
>>     > Cheers,
>>     >
>>     > Alex Band
>>     > Product Manager
>>     > RIPE NCC
>>     >
>>     > [1] https://tools.ietf.org/html/rfc6793
>>     > [2] 
>> https://www.iana.org/assignments/iana-as-numbers-special-registry/iana-as-numbers-special-registry.xhtml 
>>
>>
>>
>>
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidrops
>

v2.23.0 | Report a Bug | By Email