Re: [Sidrops] draft-sidrops-rpkimaxlen

George Michaelson <ggm@algebras.org> Thu, 11 March 2021 15:07 UTC

Return-Path: <ggm@algebras.org>
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 B0E9E3A1018 for <sidrops@ietfa.amsl.com>; Thu, 11 Mar 2021 07:07:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, 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=algebras-org.20150623.gappssmtp.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 AUywXsJ_48ZU for <sidrops@ietfa.amsl.com>; Thu, 11 Mar 2021 07:07:45 -0800 (PST)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 128023A1047 for <sidrops@ietf.org>; Thu, 11 Mar 2021 07:07:45 -0800 (PST)
Received: by mail-lf1-x12c.google.com with SMTP id k9so40278870lfo.12 for <sidrops@ietf.org>; Thu, 11 Mar 2021 07:07:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=BhA35B6i3UnRUWUrF4uM/p8JE+OTFlSxMZbFStXdZTk=; b=evJzkl5NTP2VkWS5gU2qMJAjjlx/p+b7LB0h/AvHrGyDvhdEvvXDSdXryfYkDsuR7L 3ZAMaoVWusojgz+ibGE1LNqpvYUG7c+wnf8FqIFQQ/e3XZPY5LLlZXtjTm4OmLhw9gsL er7NwDTDMz4eVFSPfJoKgGyL/5EAL5CYTdKxvKUB59H+3R1r/7lqLynbaYReP6hrMN2/ s7iUW94xr5ma1SA8IR6dUzdPJL1SVI8TqCfa1mkRnssd+TjNgsk07KqbiQ557UIHYjFo JAzO8A+LEiRHU9lZqW2hADT5A2w2w/+acx/yWoWAGLtjOkfFUArBqvn8yJUHpBYJHIes TExw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=BhA35B6i3UnRUWUrF4uM/p8JE+OTFlSxMZbFStXdZTk=; b=XDGPhHjZQpiqJXk6HQBVUfLFQi5wDm/h5G7rrDIaEXqa+VA9wBqdqwtas6+xDX1OBK WLc8FUJ9NzpxpgCKLImvq3xaV4tnIvh8SwGbZngt1lHhkKrZSTDPlxXYmKZp6PSimGTj KV3Qnhg5lCufS6tyqp6RzA1KVA/5GhAaxN/NFIeh1RHlvKIl/5oRUtUe45T2Rprr399W 5xfzMde7IjxpGBvD4c8UdCsVpjZOBqXbLY/ZtcSpjzpFSJVx/9YpbgbEGvL6vt3Xnvyd /jukr0rknyMM0ZAfBOmmGfpQyT15ZMKvq228eg8vW1hSiJKveCtXdtE2NTmVki7VhCZk Q98Q==
X-Gm-Message-State: AOAM532ddpC/EnVFjvFIjgGYQm6oIen6KhlZdbMwMONR+M5YtFWGTxWa nXMFtl5YBNVEanfZt+I8v4xNo1HH6GyS/etT/al4P6M0iTg=
X-Google-Smtp-Source: ABdhPJw6ghVFc7/PUem6+JcvUkbWPLsv6jrq++s2iBBZgYUaX6ZTdnWXNwZ+NdMb293IPRZINNtyARRSQ1w6yx89Fu0=
X-Received: by 2002:a05:6512:12c3:: with SMTP id p3mr2448380lfg.97.1615475262436; Thu, 11 Mar 2021 07:07:42 -0800 (PST)
MIME-Version: 1.0
References: <SN6PR0901MB236677B37676FFB11A22B14D84780@SN6PR0901MB2366.namprd09.prod.outlook.com> <alpine.WNT.2.00.1902240047270.4012@mw-x1> <SN6PR0901MB23662F6907DD092EA0EC988184790@SN6PR0901MB2366.namprd09.prod.outlook.com> <alpine.WNT.2.00.1902241416230.4012@mw-x1> <SN6PR0901MB2366DDDAB75A1619AD5A952E847A0@SN6PR0901MB2366.namprd09.prod.outlook.com> <alpine.WNT.2.00.1902250951230.4012@mw-x1> <BYAPR11MB32073F176C7DDB3D26EDA2A4C0919@BYAPR11MB3207.namprd11.prod.outlook.com> <D3B25842-51A0-4CBD-8602-E5DE4ABCCFA7@rpstir.net>
In-Reply-To: <D3B25842-51A0-4CBD-8602-E5DE4ABCCFA7@rpstir.net>
From: George Michaelson <ggm@algebras.org>
Date: Fri, 12 Mar 2021 01:07:31 +1000
Message-ID: <CAKr6gn3RuYQ3Z5SrgWohe18Hjoh=QqJiTRd1N5wd47r6s0owqQ@mail.gmail.com>
To: "sidrops@ietf.org" <sidrops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/tPleH4LPtxR69aCj2igGtEshH8o>
Subject: Re: [Sidrops] draft-sidrops-rpkimaxlen
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 11 Mar 2021 15:07:50 -0000

Is there a role for use of AS0 ROA, to "punch out" the elements
between /len and /maxlen, that are not "wanted" in routing?

Is there a role for short-life AS0 ROA, to mark the "emergency use"
more specifics, So they can come live on the time for the AS0 to die
out or be repudiated, but not have to be announced until needed?

(C/F Randy: George: stop inventing things we don't need) also (C/F
this may not actually be a new thought bubble)\

-G

On Thu, Mar 11, 2021 at 5:34 PM Di Ma <madi@rpstir.net> wrote:
>
> Jakob,
>
> > 2021年3月10日 21:07,Jakob Heitz (jheitz) <jheitz=40cisco.com@dmarc.ietf.org> 写道:
> >
> > I agree that a hijack is made easier when a ROA exists without a corresponding BGP advertisement.
> >
> > Implementing DDOS and RTBH as indicated in the draft is difficult without the ROAs for the required BGP announcements. As indicated in the draft, creating and distributing the ROAs required for RTBH and DDOS scrubbers is time consuming.
> >
> > Note that these ROAs are not required throughout the entire BGP space, the world.
> > These ROAs are only needed near the AS requiring these services, thus distributing them
> > around the entire world, just for some local RTBH implementation is disruptive to the
> > rest of the world.
> >
> > To help with these "limited distribution ROAs" that are required quickly, and in
> > a smaller space than the entire BGP space, I propose to invent a new BGP address
> > family to publish them. Using BGP to publish a ROA enables fast distribution
> > and allows to limit the distribution to only those ASes that need it.
>
> As I am maintaining RPSTIR the RP Software, I have been working on a feedback mechanism to enable RP to learn from BGP announcements to establish local/neighbor view. In the context of RPKI, I see those ASes sharing the same one RP are local.
>
> I think your proposed "limited distribution ROAs”  is going to help create local/neighbor view.
>
> Granted, we may have the ROA validation by RP not the router itself and should work on the interface between them.
>
> >
> > Anybody want to help me write a draft?
>
> Count me in if you think an RP implementor can help.
>
> Di
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops