Re: [Sidrops] Minor comments on draft-ietf-sidrops-aspa-profile-00

Tim Bruijnzeels <> Tue, 08 October 2019 06:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D31F412000F for <>; Mon, 7 Oct 2019 23:49:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EYweKl6oa3No for <>; Mon, 7 Oct 2019 23:49:44 -0700 (PDT)
Received: from ( [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A91BD1200B5 for <>; Mon, 7 Oct 2019 23:49:44 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 80F951708F; Tue, 8 Oct 2019 08:49:39 +0200 (CEST)
Authentication-Results:; dmarc=fail (p=none dis=none)
Authentication-Results:; spf=fail
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1570517380; bh=dkJ7EY4Ounq3Kk22780snGSgyEyEYzpXdEllVTf1qPs=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=vlMwu7MCNuGyPDjqvs8oyBlqHnjSSiAHy67R758e2HjZdTDec7GutsccxcsB/Tb26 x5jgLokQnh/WMDONwi7kFjfyA9HsDzmBnmjpGLZx3r1fAZ/p4wGugG5ZKCfdZjSjTx E53Tsu5zQPGuADqLKpnnJnQnsr/s27clpfyfVUSE=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Tim Bruijnzeels <>
In-Reply-To: <>
Date: Tue, 08 Oct 2019 08:49:15 +0200
Cc: Nick Hilliard <>, Jay Borkenhagen <>, SIDR Operations WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: "Jakob Heitz (jheitz)" <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [Sidrops] Minor comments on draft-ietf-sidrops-aspa-profile-00
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: Tue, 08 Oct 2019 06:49:47 -0000


So, to re-iterate: I don't think the problem of getting only a sub-set of ASPA objects is very likely to occur, especially when using RRDP. With RRDP there are deltas that provide transactionality in publication, which at least allows operators to publish multiple objects as a single delta. But, of course, their CA software has to support this idea, rather than publish objects (+mft + crl) one by one.

However, having the option of multiple provider ASNs in a single object allows for a publication strategy (using a fixed named object) that avoids the issue altogether, as a bonus I find it a bit easier to manage for my particular implementation, and it saves a bit of space (CMS wrapping, EE cert 2048 with bit key). And on the other hand, I don't think that having:


Instead of:

	providerASID  ASID

adds much in terms of complexity, and I do not see any other clear drawbacks (e.g. fate sharing).

If multiple provider ASNs are allowed I would go on to RECOMMEND that a single object is used, but in principle implementations can still have multiple ASPA objects, each with a SEQUENCE OF 1 ASID. I expect that RPs will validate ASPA objects and build up a list of 'Validated Customer Provider Relations', and that this list/deltas - excluding duplicates - is communicated to routers in a new version of the RPKI-RTR protocol. So, it should not matter if the relations were found on 1 or more objects.

In ROAs we can only have one ASN, so multiple are needed in case a prefix is multi-homed. Although, in retro-spect multiple ASNs could have been a nice idea here too, but I don't think the problem is anywhere near big enough to warrant a re-design of the ROA spec.


> On 8 Oct 2019, at 00:27, Jakob Heitz (jheitz) <> wrote:
> If the customer-provider objects are individual, then a relying party
> may have a partial list of providers for one customer.
> If all the providers for one customer are in a single object,
> then, upon a change, the RP can have either the old object
> or the new object, but never a partial view.
> A partial view, IMO is worse that having the old view a little longer
> than possible. A partial view can cause some AS-paths to be considered
> invalid when they are not.
> Regards,
> Jakob.
> -----Original Message-----
> From: Sidrops <> On Behalf Of Nick Hilliard
> Sent: Monday, October 7, 2019 5:32 AM
> To: Jay Borkenhagen <>
> Cc: SIDR Operations WG <>
> Subject: Re: [Sidrops] Minor comments on draft-ietf-sidrops-aspa-profile-00
> Jay Borkenhagen wrote on 07/10/2019 12:56:
>> It's critical that users of ASPA data operate using a complete set of
>> an ASN's authorized upstream ASNs.  The simplest way to communicate
>> such a verifiably-complete set is to use a single object.
> bits of me agree with this, but other bits not.  It's shifting the 
> problem from an RPKI database synchronisation problem to a 
> human-oriented data synchronisation problem.  Both are hideously 
> difficult problems to solve, but the one which involves human input is 
> almost certainly less reliable.
> Nick
> _______________________________________________
> Sidrops mailing list
> _______________________________________________
> Sidrops mailing list