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

Alexander Azimov <a.e.azimov@gmail.com> Sun, 06 October 2019 20:46 UTC

Return-Path: <a.e.azimov@gmail.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E9A1200E5 for <sidrops@ietfa.amsl.com>; Sun, 6 Oct 2019 13:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJ28Tn5PHP7r for <sidrops@ietfa.amsl.com>; Sun, 6 Oct 2019 13:46:31 -0700 (PDT)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EDC51200CE for <sidrops@ietf.org>; Sun, 6 Oct 2019 13:46:31 -0700 (PDT)
Received: by mail-oi1-x232.google.com with SMTP id k9so9973326oib.7 for <sidrops@ietf.org>; Sun, 06 Oct 2019 13:46:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <1CF3E143-98E7-4B66-AEE5-02617A639BCC@nlnetlabs.nl>
In-Reply-To: <1CF3E143-98E7-4B66-AEE5-02617A639BCC@nlnetlabs.nl>
From: Alexander Azimov <a.e.azimov@gmail.com>
Date: Sun, 6 Oct 2019 23:46:19 +0300
Message-ID: <CAEGSd=AH5hNf4vm=f4ztcMnDDrPLxE-tZoHHjmcWDO7OVo5pxQ@mail.gmail.com>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a16cd2059444079b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/JFM877ILbsnpTUsui83A7lNI4xM>
Subject: Re: [Sidrops] Minor comments on draft-ietf-sidrops-aspa-profile-00
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=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 <tim@nlnetlabs.nl>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
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>


-- 
Best regards,
Alexander Azimov