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

Alexander Azimov <> Sun, 06 October 2019 20:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98E9A1200E5 for <>; Sun, 6 Oct 2019 13:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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_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 VJ28Tn5PHP7r for <>; Sun, 6 Oct 2019 13:46:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0EDC51200CE for <>; Sun, 6 Oct 2019 13:46:31 -0700 (PDT)
Received: by with SMTP id k9so9973326oib.7 for <>; Sun, 06 Oct 2019 13:46:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wM3qoT/MOy+BgwTX+qAj94UoToiuVql2Sa4eqiIi0qM=; b=ja7xhthMYJEyhxUT3VkR/CuKNiny0jUhBUfyRyMQydZJ3CWLhkTs9bFOEVkt1UVqAy 2BHGnHNzlpvcYN3fJzU8cQr4pqzT3GH0VcRnfTITtNvp3/Ivwmu091ulpp57ewt2AzKK oVpWPu+2OuW4060fHvInF0vwATLl+EEIyAWBsGhGa6LrMsEUFL3lCIAEfEHmFkSALNX3 rR6HZwt/DrE7TiNK+cUNFfxuWcVdvIPajk4YCkhfOU5gyhjzmX4qK6atYwVond/bk15h OAyFCA/4RtGj7alg+JlyekX6bJfxc9/dlNmLI+WxpLoVjrGu1JcoHqqF6PE3f4mS7NXV srUw==
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=wM3qoT/MOy+BgwTX+qAj94UoToiuVql2Sa4eqiIi0qM=; b=I7oveaH7GWYo4ExwM1WDVR5Zw1nrKr4h6AG3s31tSxtuVz4VqcknDnmdqgiCdtpmXa nS88hBjgwIBo5FKvvVPeuUer3bFQERnNCqiaaN3McMix/ap4oOSYMPa1anCxAFMMrNRH zTMt8fCjCb1/Qwik/GaV+dvYlX+0BjhRVk276Xq/cdfXNlAZ1T1ZfhMbidY/eKZYE0pK 4NtC49TrZLHQgPy724wPCkD2sL2NEjhI88+UWM4W26vADHoYF8C/2lrkImogZyS6J4JW xCToMfohASSK5oDVqghExqlS2foTodI8uD+N7pbYvKZwn0O7ASWkjfmsAwx4Tf+2iEAf nsTw==
X-Gm-Message-State: APjAAAVsiZW9bOMcpAyl8irEW7I4zvNpkcOPG5PBtOdkGxJ35mg+kWuV tayIIv1VvqVxi6sjO56sBRNA4W+MHvYOWfz3zKgoC7UtXfE=
X-Google-Smtp-Source: APXvYqynelZGL+p6msAhCETbbSAi2DwkRmChJztXuA2KrVRKfKxapTs/jExa7cbvSN/owZl40sNV9uZ6duf2ZRpz/gI=
X-Received: by 2002:aca:b4d7:: with SMTP id d206mr16040201oif.139.1570394790258; Sun, 06 Oct 2019 13:46:30 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Alexander Azimov <>
Date: Sun, 6 Oct 2019 23:46:19 +0300
Message-ID: <>
To: Tim Bruijnzeels <>
Cc: SIDR Operations WG <>
Content-Type: multipart/alternative; boundary="000000000000a16cd2059444079b"
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: Sun, 06 Oct 2019 20:46:34 -0000

Hi Tim!

Thank you for the detailed overview.

Correct if I'm wrong, the mentioned problem with rsync can also affect
ROAs, am I right? For ROA it is just less critical since prefixes with
multiple originators are not the majority of the routing table.

ср, 21 авг. 2019 г. в 12:11, Tim Bruijnzeels <>nl>:

> Hi all,
> Triggered by an email exchange with Alexander, I figured I would send my
> (minor) comments on the aspa profile to the list as well.
> = Multiple "providerASID"
> For ASPA verification it's important that routers get all "providerASIDs"
> for a "customerASID". Since it's a single "customerASID" who signs the ASPA
> I think it would be best to allow all "providerASIDs" in a single object.
> Like so:
> OLD:
>        ASProviderAttestation ::= SEQUENCE {
>            version [0] ASPAVersion DEFAULT v0,
>            AFI  AddressFamilyIdentifier,
>            customerASID  ASID,
>            providerASID  ASID }
> NEW:
>        ASProviderAttestation ::= SEQUENCE {
>            version [0] ASPAVersion DEFAULT v0,
>            AFI  AddressFamilyIdentifier,
>            customerASID  ASID,
>            providerASID  SEQUENCE (SIZE(1..MAX)) OFASID }
> Of course it's possible to make separate ASPA objects for each
> "providerASID", but I think it introduces avoidable risks with no clear
> benefits. When managing separate objects signing CAs would need to make
> sure that they publish changes as a set. If RPs use rsync as the fetch
> protocol they may learn of some, but not all, objects if the repository is
> being updated just as they are fetching.
> The use of RRDP can mitigate this issue, but having a single object in
> this case is cheap and avoids some of the risks. An RP would always see the
> full set (for the moment that it validates).
> = Small EE certs
> The draft currently has:
>       The autonomous system identifier delegation extension [RFC3779] is
>       present in the end-entity (EE) certificate (contained within the
>       ASPA), and the customer AS number in the ASPA is contained within
>       the set of AS numbers specified by the EE certificate's autonomous
>       system identifier delegation extension.
> I think it's better practice to require that:
>       The autonomous system identifier delegation extension [RFC3779] MUST
>       be present in the end-entity (EE) certificate (contained within the
>       ASPA), and MUST contain a single AS number that matches the customer
>       AS number. The IP address delegation extensions MUST NOT be used.
> The reason for this is fate-sharing. If any of the other irrelevant
> resources on the EE certificate would no longer be contained on the CA
> certificate - e.g. because of a resource transfer - then the object as a
> whole would become invalid.
> There is still discussion about transfers and the deployment of
> 'reconsidered' validation rules. But.. I think that's best discussed
> outside of this draft. Here it seems that the problems can simply be
> avoided by having a single AS on the EE cert.
> = Add file extension to section 6 (IANA considerations)
> In addition to the OIDs I believe a filename extension should be
> registered.
>    IANA is to add an item for the Signed TAL file extension to the "RPKI
>    Repository Name Scheme" created by [RFC6481] as follows:
>           Extension  |   RPKI Object              | References
>           -----------+-------------------------------------------
>            .asp      |   Trust Anchor Keys        | [this document]
> (of course feel free to chose another extension - I think four characters:
> .aspa would also be fine)
> File extensions were introduced to help RPs in parsing - so they don't
> have to do trial an error parsing of objects as all possible types. The
> OIDs are not quite enough, because certificates and CRLs are not RPKI
> signed objects.
> Kind regards
> Tim
> _______________________________________________
> Sidrops mailing list

Best regards,
Alexander Azimov