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

Tim Bruijnzeels <tim@nlnetlabs.nl> Tue, 05 November 2019 17:50 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 97719120104 for <sidrops@ietfa.amsl.com>; Tue, 5 Nov 2019 09:50:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.998
X-Spam-Level:
X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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: 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 9nDdg1tmdqIA for <sidrops@ietfa.amsl.com>; Tue, 5 Nov 2019 09:50:05 -0800 (PST)
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 33B7E12001A for <sidrops@ietf.org>; Tue, 5 Nov 2019 09:50:05 -0800 (PST)
Received: from [100.64.112.74] (unknown [193.173.217.255]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 4954A26B84; Tue, 5 Nov 2019 18:50:03 +0100 (CET)
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=1572976203; bh=fSKzJWnnpztzCJsFI/CdLxwqscNG6Vugkhm2KK+EBSg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=rIa+n/XfjihaOh7lH5DqWCvlErfj5+7yu83C1hGaj1ZPRb4Z34oF3N430733Rex2D aRRkUDV+3oAp4P/wQqtyIoHL3uzQ/H71VIC2q5gbBJoQWq8FvzbzRWSwPxZVS2pbrq TFgTw4eOuZtxCcXPjm8nKvl14OqDJLa3Ct/GHtN4=
Content-Type: multipart/alternative; boundary="Apple-Mail=_5F1BE6D6-91C6-48A5-9072-0363EA5C5F75"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <CAEGSd=BQqkU1ru_GynmgxruRmvH5VgBvC6BgJjzLM4oZdTSh_Q@mail.gmail.com>
Date: Tue, 5 Nov 2019 18:50:02 +0100
Cc: "Jakob Heitz (jheitz)" <jheitz@cisco.com>, Jay Borkenhagen <jayb@braeburn.org>, SIDR Operations WG <sidrops@ietf.org>, Nick Hilliard <nick@foobar.org>
Message-Id: <FDB76D0A-700D-49B7-9B19-A9C6D77B77AB@nlnetlabs.nl>
References: <1CF3E143-98E7-4B66-AEE5-02617A639BCC@nlnetlabs.nl> <CAEGSd=AH5hNf4vm=f4ztcMnDDrPLxE-tZoHHjmcWDO7OVo5pxQ@mail.gmail.com> <m2sgo5zad3.wl-randy@psg.com> <9579DFEC-6653-4CD2-A4DE-2DC5B7427782@nlnetlabs.nl> <23963.10240.12287.137386@oz.mt.att.com> <29669e33-2ae9-1aab-0cf2-63e9d0f3857e@foobar.org> <BYAPR11MB375183DF6D321438827C39FCC09B0@BYAPR11MB3751.namprd11.prod.outlook.com> <39E6D50C-7112-4C0B-90BF-99C91665C193@nlnetlabs.nl> <CAEGSd=B90Kwnbfc_xd2stN4meUsXCTjhR3N6QmQWqhMHuGCEqQ@mail.gmail.com> <BN8PR11MB3746BB52BF5F0E4779C5F73FC0900@BN8PR11MB3746.namprd11.prod.outlook.com> <E74F9B72-7AAC-4A00-B604-A7628F2CC9F5@nlnetlabs.nl> <CAEGSd=BQqkU1ru_GynmgxruRmvH5VgBvC6BgJjzLM4oZdTSh_Q@mail.gmail.com>
To: Alexander Azimov <a.e.azimov@gmail.com>
X-Mailer: Apple Mail (2.3594.4.19)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/v7KyAfmTL1LMtEJ7c53C88diwgY>
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: Tue, 05 Nov 2019 17:50:08 -0000

Hi Alexander,

Thank you for updating. I gave it a quick read only so far, and it looks good.

I have one comment on section 4, where you have:

   o  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.

This is technically fine. But, I would really recommend that the EE certificate is restricted to contain the customer AS only. This is the only resource that is needed here, and including other resources introduces an avoidable risk of the certificate to become invalidated if any of those is no longer contained by the CA certificate above this object.

Tim


> On 4 Nov 2019, at 21:50, Alexander Azimov <a.e.azimov@gmail.com> wrote:
> 
> Hi Tim, all,
> 
> I've just submitted a new version of ASPA profile and verification drafts. 
> As it was suggested in this thread, the ASPA object is transformed to (customer, set_of_providers).
> 
> We also added 'unknown' state for verification procedure that might be useful at medium/high adoption rates. 
> There are other minor changes in the documents, including some drawings, which, I hope, will make the algorithm easier to read.
> 
> We are looking for your feedback, and it is time to also look for the implementations. 
> I know at least about one implementation on top of BIRD - thanks to Eugene Bogomazov and Ondrej Zajicek. 
> 
> If there are already other implementations in place - please let me know.
> 
> вт, 15 окт. 2019 г. в 16:35, Tim Bruijnzeels <tim@nlnetlabs.nl <mailto:tim@nlnetlabs.nl>>:
> Hi Jakob, all,
> 
>> On 14 Oct 2019, at 23:49, Jakob Heitz (jheitz) <jheitz@cisco.com <mailto:jheitz@cisco.com>> wrote:
>> 
>> The time for such enhancements is not now and may never happen, but we should think about it when choosing the format for the object.
> 
> I am not convinced about that. The object has a distinct OID and version, either of which could be updated by possible future versions..
> 
> Tim
> 
> 
> 
> -- 
> Best regards,
> Alexander Azimov
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops