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

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Mon, 14 October 2019 21:49 UTC

Return-Path: <jheitz@cisco.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 CC24512003F for <sidrops@ietfa.amsl.com>; Mon, 14 Oct 2019 14:49:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 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_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=NzQi3m+A; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zc+diKMH
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 QxNBfTmm0TUL for <sidrops@ietfa.amsl.com>; Mon, 14 Oct 2019 14:49:15 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17C5A12003E for <sidrops@ietf.org>; Mon, 14 Oct 2019 14:49:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24784; q=dns/txt; s=iport; t=1571089755; x=1572299355; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9zbZjF/MkpeYhmdnFHEkteKToKGNINWjheV2WR/UapQ=; b=NzQi3m+AA29qSjUrnbK3gdeE14lGQgWtZ4hwx8pBkz4czyPcbTbn2kmc KhbsXtqLD2qyz8Nfxap9yXv6rBkSL3+vZUkm+R79vRIPlGl4sE1p4DNuJ UnG+achnASfWRV2w4oSmvOnXHgZITZm8EybaH4RM1rNa6gDqk+5AaePyz 0=;
IronPort-PHdr: =?us-ascii?q?9a23=3AbRhVzB8ASJCEx/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/bR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcyFBEznPtbhbjcxG4JJU1o2t3w=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAAAc7KRd/5xdJa1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFpAwEBAQELAYEbLyQsBWxXIAQLKgqEGoNHA4p?= =?us-ascii?q?KglyTHYRhgS6BJANUCQEBAQwBARgBCgoCAQGBTIIvRQIXgkckNgcOAgMJAQE?= =?us-ascii?q?EAQEBAgEFBG2FLQyFSwEBAQECAQEBEBEKEwEBLAQHAQQHBAIBBgIOAwQBAQE?= =?us-ascii?q?nAwICAiULFAkIAgQBDQUIGoMBgXlNAw4gAQIMlDKQYgKBOIhhdYEygn0BAQW?= =?us-ascii?q?FChiCFwMGgTQBjA0YgUA/gRFGgkw+gmEBAYEtNhUWCYJYMoIKIo9vhTeJLo5?= =?us-ascii?q?zCoIilTSZQI4tmTcCBAIEBQIOAQEFgVgBMioagRRwFTuCbFAQFIFPDBeDUIU?= =?us-ascii?q?UhT90gSmNUyuBBAGBIgEB?=
X-IronPort-AV: E=Sophos;i="5.67,296,1566864000"; d="scan'208,217";a="356866354"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Oct 2019 21:49:14 +0000
Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x9ELnDoa006907 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Oct 2019 21:49:13 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 14 Oct 2019 16:49:13 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 14 Oct 2019 17:49:11 -0400
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 14 Oct 2019 16:49:10 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SoBItDCB6Aua4/z+KoMgX5BkZc2vzljKv2Baz9QQcAEILRE4FFiPWTDTkFCGAhJKmp4B/Qb18Vt7NPr4ONbUcvp8kJ6qSNIknqawnbEfdCfIdYgk+BwrMH7tyd+FkePBKAsvJx0TWtdgHEWicSSh/inTiLwUgn2BV81QKXAel51X44VYRPMvEJDTYH/jddIsh4J5Ewi+uxWjOBUeQ+/7fAYWurCSm7xnsuJKvW4xMWhJMNJwTq1oG9uuXpf0lmnPpyVaUXP1YeFIquG2RGaGlU/a9UssScm11ZD6KNuYEtXk1pNLY/r/O10g52Oq/a0b3QgyQNZI9xFRVMuN5nMLdg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9zbZjF/MkpeYhmdnFHEkteKToKGNINWjheV2WR/UapQ=; b=UL807FdXKyHLHqvygIn75UgyBDB5yABeCLJCSRZjB89P414xVmXF0sQzndGJNQrjOyIdzbLCxUDC3i/tXFRogKevyQGAlJbtZtqED2bEhI8I17c9Ku4XJ5hvbrkQdm9LKpvIeozcDbPtNgTlI+qQSLTpuBvkgSQLutoKQi5WmUcQ3UdGh/CfEwtPDe1SbGFxdHQyaoGJX2KQ5dnSmY9Kj1igTFgUX4NSznzftaghgGxh1JvzYg7b9w5x29/+HT7mF6k4DpGsDtC8J30fK+TVdPmYBiNfztD1B9K41iiUaTM/KAqGGU2RNo3Z0c6UmiTyKyrVfl90Z7VzarwfKu/+iA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9zbZjF/MkpeYhmdnFHEkteKToKGNINWjheV2WR/UapQ=; b=zc+diKMHJKYLPrZhMc68+oXOuf52j+4y7jw7SUnt+3NdaHHVNy8eQX72oIO2oPsXCFN3yCe594+WrtIedNVksik6EW4Q9ps9QONVHQ60vkCEPcocpzo92PPSXgSBYEM/QN8y/cpRrArORVFA/u8RdWSdkx2YpUAvWcP5Dn/SIxs=
Received: from BN8PR11MB3746.namprd11.prod.outlook.com (20.178.221.23) by BN8PR11MB3540.namprd11.prod.outlook.com (20.178.218.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.19; Mon, 14 Oct 2019 21:49:09 +0000
Received: from BN8PR11MB3746.namprd11.prod.outlook.com ([fe80::c1ad:20a:be24:fe90]) by BN8PR11MB3746.namprd11.prod.outlook.com ([fe80::c1ad:20a:be24:fe90%5]) with mapi id 15.20.2347.023; Mon, 14 Oct 2019 21:49:09 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Alexander Azimov <a.e.azimov@gmail.com>, Tim Bruijnzeels <tim@nlnetlabs.nl>
CC: SIDR Operations WG <sidrops@ietf.org>, Jay Borkenhagen <jayb@braeburn.org>, Nick Hilliard <nick@foobar.org>
Thread-Topic: [Sidrops] Minor comments on draft-ietf-sidrops-aspa-profile-00
Thread-Index: AQHVWAB1SjQJpUEXD0ai6mvWNAHq36dOXjSAgAA4PQCAAIoWAIAAPBAAgAAJy4CAAKS80IAAjeCAgApbfgCAAAZhAA==
Date: Mon, 14 Oct 2019 21:49:09 +0000
Message-ID: <BN8PR11MB3746BB52BF5F0E4779C5F73FC0900@BN8PR11MB3746.namprd11.prod.outlook.com>
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>
In-Reply-To: <CAEGSd=B90Kwnbfc_xd2stN4meUsXCTjhR3N6QmQWqhMHuGCEqQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jheitz@cisco.com;
x-originating-ip: [128.107.241.180]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 087171b3-334e-42bf-f451-08d750f057e3
x-ms-traffictypediagnostic: BN8PR11MB3540:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <BN8PR11MB35405DBD5E4C486853BCB570C0900@BN8PR11MB3540.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 01901B3451
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(136003)(346002)(366004)(376002)(199004)(189003)(13464003)(53754006)(74316002)(55016002)(14454004)(66574012)(446003)(11346002)(66066001)(486006)(99286004)(6246003)(4326008)(5660300002)(476003)(71200400001)(76116006)(14444005)(86362001)(33656002)(256004)(66476007)(66556008)(64756008)(66446008)(71190400001)(66946007)(6306002)(478600001)(6436002)(54896002)(236005)(9686003)(966005)(316002)(52536014)(76176011)(25786009)(54906003)(7736002)(110136005)(2906002)(606006)(229853002)(6506007)(53546011)(102836004)(7696005)(26005)(186003)(3846002)(6116002)(790700001)(8676002)(81166006)(81156014)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3540; H:BN8PR11MB3746.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: G7X1LYtW6yS/WmZhrVdSGBhdfqPxU9PBxh4Mchqshc2VNbpENJLk6p7wKOQrEHIorDLlwpvFFY7dKb9clC1+7Id/w6G3ASMpt7yWAkDuspktDLfXlm4K9313FXEkZO+6geSmZOtPRgjHitl3k3FpXItL17zwWtdxkHe/fvyEWtb22xcOM8q7msVNBddCRYRARp46Z8ImhRR916sGgEUuXgLh4RoI7KftAngKkxVgp5bdjkd6ymLKG96NR0OlvNvd+NR84EH8HKj16kXAUEnkCwv+XPch8l6YdsS9ZE84HPWMsT+pQCvjxMDqxlPH3A3i6QqqdBRER6SNBh0jcsPZad0fJ+b9/ddTz7cr7nxkgrf6SMqi3ZNdf5DiNUks1l9ye17GNfdkuRpGtqsOqWG6P6dUJHeFp9TQrxPb1QVM5L9cxjDszBy/8P87GMMnuQzFAym1kfhkiT0hOO+PPov8yw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BN8PR11MB3746BB52BF5F0E4779C5F73FC0900BN8PR11MB3746namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 087171b3-334e-42bf-f451-08d750f057e3
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2019 21:49:09.2055 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: khDGcJLVxgfoXWhGSHQaF/VgLhBHaRkyqOPp2m52cCg2nglO7Nj4ojJViGM4oHoGXengvrIOdVzyeEuO0oT6mA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3540
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/CblTMjRadQy2SLR_tljP6j6yMiI>
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: Mon, 14 Oct 2019 21:49:19 -0000

I think the ultimate test of whether an AS-path conforms to policy is that the as-path contains only ASNs that are authorized by the endpoints to carry traffic between the endpoints. ASPA is a blunt hammer to achieve this. To be sure, I think it hits most of the nails and for the nails it misses, it has siblings. I want to leave the door open to improve it so it can hit more nails.

One improvement would be to add a prefix-set to a provider: The stated provider is provider for the stated prefixes. Another would be to give an AS the ability to exclude any ASNs from anywhere in the AS-path that it is an endpoint of, even if its upstreams allow it. This would have to be conditional on a prefix-set at least.

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.

Regards,
Jakob.

From: Sidrops <sidrops-bounces@ietf.org> On Behalf Of Alexander Azimov
Sent: Monday, October 14, 2019 1:59 PM
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: SIDR Operations WG <sidrops@ietf.org>rg>; Jakob Heitz (jheitz) <jheitz@cisco.com>om>; Jay Borkenhagen <jayb@braeburn.org>rg>; Nick Hilliard <nick@foobar.org>
Subject: Re: [Sidrops] Minor comments on draft-ietf-sidrops-aspa-profile-00

Hi all,

I would try to summarize the points that were presented in this thread.

The question is whether we should define ASPA like it was done for ROAs or should we do it in a slightly different and slightly more reliable manner.
The data structure that we need at the router to verify ASPATH is a simple {customer: set of providers}. And to have a reflection of such tuple it in one RPKI object seems to be native (+ all points that were listed above). If we unbound ASPA object structure from ROA-like structure we may also get rid of ASPA0 - empty set is a simple form to signal that ASN does not have any transit providers. So, the spec should say:

providerASID  SEQUENCE (SIZE(0..MAX)) OF ASID

In this case, to signal that prefix should not be seen in the BGP default-free zone ROA0 should be issued; to signal that ASN is provider-free ASPA-EMPTY (instead of ASPA0) should be issued. If we believe that this will not add ambiguity for the users I'm ok to change it.

вт, 8 окт. 2019 г. в 09:49, Tim Bruijnzeels <tim@nlnetlabs.nl<mailto:tim@nlnetlabs.nl>>:
Hi,

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:

        providerASID  SEQUENCE (SIZE(1..MAX)) OF ASID

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.

Tim



> On 8 Oct 2019, at 00:27, Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>> 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 <sidrops-bounces@ietf.org<mailto:sidrops-bounces@ietf.org>> On Behalf Of Nick Hilliard
> Sent: Monday, October 7, 2019 5:32 AM
> To: Jay Borkenhagen <jayb@braeburn.org<mailto:jayb@braeburn.org>>
> Cc: SIDR Operations WG <sidrops@ietf.org<mailto:sidrops@ietf.org>>
> 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@ietf.org<mailto:Sidrops@ietf.org>
> https://www.ietf.org/mailman/listinfo/sidrops
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org<mailto:Sidrops@ietf.org>
> https://www.ietf.org/mailman/listinfo/sidrops

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<mailto:Sidrops@ietf.org>
https://www.ietf.org/mailman/listinfo/sidrops


--
Best regards,
Alexander Azimov