From nobody Thu Mar 11 07:07:51 2021 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 B0E9E3A1018 for ; 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 ; 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 ; Thu, 11 Mar 2021 07:07:45 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id k9so40278870lfo.12 for ; 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: In-Reply-To: From: George Michaelson Date: Fri, 12 Mar 2021 01:07:31 +1000 Message-ID: To: "sidrops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > > Jakob, > > > 2021=E5=B9=B43=E6=9C=8810=E6=97=A5 21:07=EF=BC=8CJakob Heitz (jheitz) <= jheitz=3D40cisco.com@dmarc.ietf.org> =E5=86=99=E9=81=93=EF=BC=9A > > > > I agree that a hijack is made easier when a ROA exists without a corres= ponding BGP advertisement. > > > > Implementing DDOS and RTBH as indicated in the draft is difficult witho= ut 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 d= istributing them > > around the entire world, just for some local RTBH implementation is dis= ruptive to the > > rest of the world. > > > > To help with these "limited distribution ROAs" that are required quickl= y, and in > > a smaller space than the entire BGP space, I propose to invent a new BG= P address > > family to publish them. Using BGP to publish a ROA enables fast distrib= ution > > 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 feed= back mechanism to enable RP to learn from BGP announcements to establish lo= cal/neighbor view. In the context of RPKI, I see those ASes sharing the sam= e one RP are local. > > I think your proposed "limited distribution ROAs=E2=80=9D is going to he= lp create local/neighbor view. > > Granted, we may have the ROA validation by RP not the router itself and s= hould 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