Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT)

Alvaro Retana <> Mon, 15 January 2018 14:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2DDF812D7F1; Mon, 15 Jan 2018 06:21:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 4wLAz464Kw4N; Mon, 15 Jan 2018 06:21:47 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DD40012D7E2; Mon, 15 Jan 2018 06:21:46 -0800 (PST)
Received: by with SMTP id a24so10752601otd.4; Mon, 15 Jan 2018 06:21:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=8pBrW+GU7fPQRCe7I2i+YMl599G8HEUTUF3rhxyoMv8=; b=jPdtr0AkkEMZnGpfLerOY95psENoL2yK7MatBKFcC21A2/5GJb650a6BQRoxdjf/Ri GsxCEHk5YYWVey5Bm4HxPia52ZscTI8agVzui3h/MpuuipGL7vmvVXaZRzVkKIP7gcZH 7KjSFFSFuc3fGVDWauRWN35F2YBE6wKDXnaxhKe6qhgybzcMvfWJ2weCHiki1gbhbGNL whCSPbDbEujHBNzldvyRr4MjiS6UwpRHligqfXyffO+2w10sTxg2rbQswrvG9QAzLK6y XmSu+qI2INJ/TY8oA80UHs9Xk+TzYoA5LHOUI6Qt+KUMX7FCaYNKyLwqA0KqwrAtcktm vI4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=8pBrW+GU7fPQRCe7I2i+YMl599G8HEUTUF3rhxyoMv8=; b=rEO++phVC5iVYo4vMI4s9tYKcUgbaWriigbok0Jl1mMb3etESSfHJs3mKAUsRBdWDY VytKfdbZcCQ0VLL25VgKgfAQTuEKY9daTcEnchAL5z/jsP3tUgEyRmtA9sIp9QwkKQyA PfeZMq81CpRgJmR4KPmmHiPQx91MXGbdRIoPz0QijlAVDYnEJm9iN2EtVaHHm7KYLjGF xbh6B9LTEx34zc/JKhCVrThS1Sg4H1RztD72dAb8Urng7qfCijQBeBtqJRdcT//KvufM jMuCUjZgXvrUkhq3AI03h0wKgqauRFlQUzJsnAEsM7xJxz0/PqGEQ8GxY0Vmp1EC5kaJ zWZg==
X-Gm-Message-State: AKwxytd05mgp+VPDuyXZeNzuzOf2ivtr4wklGYKxSdFmYxM3+VKsYuEi lsOje1uk/v/ruzBBB8Am5dWuBzbDkfZ+4m2Uz/c=
X-Google-Smtp-Source: ACJfBouufQZ+C9F7OPe71X2p4pL9LhWxw4s9v4wtxpMBuxLMSGLPCeqDP47/SwcsWuoZ9vGhjlH92Q3sIr2AzHGivLo=
X-Received: by with SMTP id b1mr16107001otj.187.1516026105884; Mon, 15 Jan 2018 06:21:45 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Mon, 15 Jan 2018 09:21:45 -0500
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
X-Mailer: Airmail (467)
MIME-Version: 1.0
Date: Mon, 15 Jan 2018 09:21:45 -0500
Message-ID: <>
To: Terry Manderson <>, Tim Bruijnzeels <>
Cc:, Chris Morrow <>,, The IESG <>,
Content-Type: multipart/alternative; boundary="94eb2c19d12082f6520562d15552"
Archived-At: <>
Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Jan 2018 14:21:49 -0000


Hi!  Any thoughts on this document?



On December 22, 2017 at 9:52:21 AM, Tim Bruijnzeels ( wrote:

Dear Terry,

We just uploaded version -10 that we hope addresses your points.

This version adds:
- explicit text in the abstract stating that this document considers
validation under a Trust Anchor only, and that overlaps between multiple
TAs are out of scope
- three examples using the validation algorithm in this document:
1- Old OID only
2- New OID only
3- A mix of old and new OIDs in a single RPKI tree
- the deployment considerations section clearly says discussion still needs
to be had, but points at example 3 as a possible deployment scenario

Kind regards,

Tim Bruijnzeels, and co-authors

> On 31 Aug 2017, at 05:29, Terry Manderson <>
> Terry Manderson has entered the following ballot position for
> draft-ietf-sidr-rpki-validation-reconsidered-08: Discuss
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thank you for considering the stability of the internet's routing system
> administrative changes to resources.
> One thing isn't quite clear to me, so I'm balloting this as a DISCUSS
with the
> plan that a small amount discussion will resolve it.
> With the definition of the new validation OID (a idea that I like BTW),
at any
> stage of the certificate issuance can the validation OID be switched?
That is a
> TA has a particular OID and down the tree an issued certificate has a
> OID? If that can't happen (and please make that clear in the document) is
> plan to migrate the set of all issued certificates to the new OID? and
> deprecate the old OID?
> Logically speaking a trust anchor cannot be thought of as over-claiming.
> you trust where the self signed cert came from, and its contents) However
> new validation constructs suggest that a TA can over-claim, but it seems
> there won't be any warning (as the example in S4.3) to highlight this
> eventuality when (in the model where all RIRs issue a TA) a resource is
> transferred from one RIR to another for the clients use. Is that
> correct? OR does this new model espouse the belief that all RIRs each
issue a
> TA that covers 0/0 and ::/0 in perpetuity? In that construct does this
> that RFC6491 should be updated or made historic?
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I get the sense that many of the ramifications for this validation change
> yet to be discovered. It worries me that from the shepherd writeup "The
> existing CA/RP code implementations will support this once published."
> experiments have been done to identify any gaps and assumptions?

sidr mailing list