Re: [Sidrops] trying to limit RP processing variability

George Michaelson <> Thu, 16 April 2020 22:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A5183A12A3 for <>; Thu, 16 Apr 2020 15:48:28 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F5keOWVjmmSk for <>; Thu, 16 Apr 2020 15:48:26 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A3DA3A12A1 for <>; Thu, 16 Apr 2020 15:48:25 -0700 (PDT)
Received: by with SMTP id f3so276284ioj.1 for <>; Thu, 16 Apr 2020 15:48:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HE2EjKBxDJyvy3rR8dlHaN1cGtHpKYz6/FoQHfwXyPU=; b=Gy9OrbYe3Ku95RKnhFpK4rAGfI3YQAKTmtRnjY6ywtAY7t+j01lcGAtV32Xfq/7dnr UUDZ1eAPHRR7qvs/dNSp7WObsJWQ9G9W1bgtDaWaCVK6QrfOqqrygtimyaM9EtZgwm9t NMPeeIslkad/qwkYH1ADvr4WiX2uf77rNdXyX5GQiaLNk36T9MsH+SN7uZQH5mqzwBZF fSKtIFcVpFw7uS1luP86GfpF6PtGFwSWjukSK8yZRAt0ektp22s7Uk/MoPMTJhBaEUzI 5xl9sNs+FzcA33CkiHvTKUVI3R3op7+WP7j//B7o9gk2ejr5Rl93RNrJ2VmVna78Kohj 5JkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HE2EjKBxDJyvy3rR8dlHaN1cGtHpKYz6/FoQHfwXyPU=; b=E3xlqxBEKE4GfaB8KaoRfufHqg8LZpznOYqoR0I9RISPoLlQzlNFd67yOVzSWDzHs7 zUBh7ukNs1sZ9W4jNnP+3d5itlhlRi59GQYZXXREwyhk1zLYzn4eT87Cw+BbQCVDw3Ac Y+bEYeodGHJMLOAQm4nl2lR8MVZOA8jDtsyuBlsxjpJL5O3NLtiHj1vSc6S8j1xfP8mF J0nh0/w/RvwC/d18nY3LDrAAaGeU/Yc3NzZCj30AVvNZ00GRiQAABFQ04VAiadXGX/aK rXKKK60qWwSIA2mI5aEKBIo8elbx5uIKylGDjfF4LWFm5SbB/6A4HNSh3RaTbsEjyNSh eVYg==
X-Gm-Message-State: AGi0PuZ6xXLoaAq8Mc4oSmeiJAAXUToPYZIc6dtPssJf7CegNiaCQ5xw Jhoxoh+0hSns7ai7lJS6zZ079eZuaEk4izan5G4V8w==
X-Google-Smtp-Source: APiQypJEMMSCwo0rA8XQL1GA6tWDzgKJtwVgneO0Tmvd8qI2oV0X3WGo7i/AxLSk+laUykcyoZu+/0AZIIZ7gp3OlIA=
X-Received: by 2002:a05:6602:34c:: with SMTP id w12mr252058iou.56.1587077303844; Thu, 16 Apr 2020 15:48:23 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: George Michaelson <>
Date: Fri, 17 Apr 2020 08:48:12 +1000
Message-ID: <>
To: Stephen Kent <>
Cc: Claudio Jeker <>, "" <>, Martin Hoffmann <>, Job Snijders <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Sidrops] trying to limit RP processing variability
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, 16 Apr 2020 22:48:28 -0000

If a ROA object can be removed and a manifest proves it has been
removed, and a CRL confirms it has not been revoked, the unknown
question is:

 * what was the semantic intent of the ROA?

If you have a previously acquired state of the ROA which meets the
manifest checksum/sig and its not in the current CRL *ITS NOT MISSING*
and you know its semantic intent. All is good. This is what
maintenance of local cached state of fetching achieves.

If you do NOT have a previously acquired state of the ROA, you cannot
know its semantic intent. Job showed me that this means a covering
aggregate ROA state which is superceded for a specific prefix can be
invalidly interpreted as applying to the more specific. Any more
specific. The semantic intent of unknown amounts of ROA covered space
defined at this level in the CA hierarchy cannot be stated
categorically because the missing ROA might modify any of them.

Therefore, the ROA states of this level of the hierarchy and children,
cannot be known categorically.

IFF (and the FF is important) you don't have a valid ROA state cached,
and you can detect from valid CRL and valid Manifest some ROA is
missing, you cannot know how it modifies the routing intent in the ROA
otherwise unaffected.

I think therefore, you have to stop processing. But the IFF part is,
if you do not have a valid prior-state fetch of the ROA. Just because
"its missing" is not sufficient. If the one you have before refetch
maches what the Manifest says is a signed state, you aren't missing