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

Tim Bruijnzeels <tim@nlnetlabs.nl> Wed, 21 August 2019 09:11 UTC

Return-Path: <tim@nlnetlabs.nl>
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 B05931208C7 for <sidrops@ietfa.amsl.com>; Wed, 21 Aug 2019 02:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl
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 n8oHcfLkw37h for <sidrops@ietfa.amsl.com>; Wed, 21 Aug 2019 02:11:12 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [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 ietfa.amsl.com (Postfix) with ESMTPS id 9240A1208BD for <sidrops@ietf.org>; Wed, 21 Aug 2019 02:11:12 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:184d:f3fa:5377:1453] (unknown [IPv6:2001:981:4b52:1:184d:f3fa:5377:1453]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id E33F1226C8; Wed, 21 Aug 2019 11:11:09 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1566378669; bh=ZzXyNd78P42S+wUnkFCkrwJZ6yPl81cXBHnbqL7XZtY=; h=From:Date:Subject:To; b=GXEg2yDOyvWSsv8GddhZqXNJm4xOz0Vgibk08uCdnoi4hC1so3VVZZ6WyGdJeii2P ABEkmku0AMbtJVv7pblnTl3mwSS8FZlsIaZs2b0QM74bRNu9koYWbt3lfOLe0/Qff2 8CW1VujEsiQuJiFBUf2UnMZhaOzWGANHjpbzq0yQ=
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 21 Aug 2019 11:11:08 +0200
Message-Id: <1CF3E143-98E7-4B66-AEE5-02617A639BCC@nlnetlabs.nl>
To: SIDR Operations WG <sidrops@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/YZiIzrtpF0TSDob4EfAnhcbXtZ8>
Subject: [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: Wed, 21 Aug 2019 09:11:15 -0000

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