Re: [Sidrops] ASPA duplicates

Randy Bush <> Mon, 04 May 2020 13:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 86F373A08AB for <>; Mon, 4 May 2020 06:39:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4d50XrZ-PksF for <>; Mon, 4 May 2020 06:39:36 -0700 (PDT)
Received: from ( [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 696A73A08A6 for <>; Mon, 4 May 2020 06:39:36 -0700 (PDT)
Received: from localhost ([] by with esmtp (Exim 4.90_1) (envelope-from <>) id 1jVbJm-0004U1-KL; Mon, 04 May 2020 13:39:34 +0000
Date: Mon, 04 May 2020 06:39:34 -0700
Message-ID: <>
From: Randy Bush <>
To: Tim Bruijnzeels <>
Cc: SIDR Operations WG <>
In-Reply-To: <>
References: <> <> <> <> <> <>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <>
Subject: Re: [Sidrops] ASPA duplicates
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: Mon, 04 May 2020 13:39:44 -0000

> This might not be easy for existing RPs - with ROAs the thought has
> also been that they are cumulative. Now you would need to keep much
> more state, and even check between all configured TAs - which until
> now could just be processed in parallel.
> I understand your reasoning, but I think this warrants at least some
> normative wording in the document and discussion in the security
> section. And most importantly I am curious to learn what RP software
> implementers think (nowadays I do the CA side, which is much easier in
> this context).

from draft-ietf-sidrops-8210bis

11.  ROA PDU Race Minimization

   When a cache is sending ROA PDUs to the router, especially during an
   initial full load, two undesirable race conditions are possible:

   Break Before Make:  For some prefix P, an AS may announce two (or
      more) ROAs because they are in the process of changing what
      provider AS is announcing P.  This is is a case of "make before
      break."  If a cache is feeding a router and sends the one not yet
      in service a significant time before sending the one currently in
      service, then BGP data could be marked invalid during the
      interval.  To minimize that interval, the cache SHOULD announce
      all ROAs for the same prefix as close to sequentially as possible.

   Shorter Prefix First:  If an AS has issued a ROA for P0, and another
      AS (likely their customer) has issued a ROA for P1 which is a sub-
      prefix of P0, a router which receives the ROA for P0 before that
      for P1 is likely to mark a BGP prefix P1 invalid.  Therefore, the
      cache SHOULD announce the sub-prefix P1 before the covering prefix