Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020

"Borchert, Oliver (Fed)" <oliver.borchert@nist.gov> Mon, 21 September 2020 21:51 UTC

Return-Path: <oliver.borchert@nist.gov>
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 617673A0AE6 for <sidrops@ietfa.amsl.com>; Mon, 21 Sep 2020 14:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.244
X-Spam-Level:
X-Spam-Status: No, score=-4.244 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.448, RCVD_IN_MSPIKE_H2=-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=nist.gov
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 tD4sq1cnJLjw for <sidrops@ietfa.amsl.com>; Mon, 21 Sep 2020 14:51:06 -0700 (PDT)
Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2125.outbound.protection.outlook.com [40.107.89.125]) (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 45A4F3A0ADE for <sidrops@ietf.org>; Mon, 21 Sep 2020 14:51:05 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a5ll54TCxz5vnNGx5tsD4rBr9OsYgbBcunoBFn9OYViPRZoGCZobg1sBAr0tpTNr2aMDHB0iWJ1Ya1B6k4aVcYUc9LzYgOtoD6osIM+/h9HQEGJENycvUz8NUFe44JTpDFO+10qaQEilGBIDtCLo+5WG1udxwDr4/vHht70VGa9vYrF3Hq+cyz5u1ilXsGdcvmCn8lDnc0Py2USds/F+Vmbegve/0eQ0XBL+G5tTtDJaJsfuNIdwOTiPPJWgeZ6p0dwooWwnMjISn1zO3tdeqC8QNl0LeCyjtwiJKFIHI/45dQIEzVe6/7Jd9QYagcMQmm1WyG122ufgSlWQewhBhA==
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=A9hzFsHDlOunkJcYThRfR0m9Ca0beZZZTR5zxesCxNg=; b=mQl4fb+BfG+BNxeA0xhTbnBJ6wmIXL5dLwQKSxZWSai6yKwf4QnBZS+kRF+sUKU6hOe3PnGIwSy6SSQQsulcd3mKJnRUQX6SRAVmPp7EcQIl7SIOVpmLvqu8WNMnlknym1l+hRekp4AWdKEocwJSCrOqDLp3BTk5GR3H9KJIGmFijfJ4hiZYCiXPj1fwrSp6vTDNdFHWSjuTFoUij+EHB0G99erNfqCcaZRMYpTc0ycyhRBrcvwY9mMPRBlUD4k5QCNpXIt3Ww2EFCn52FPZNoO1EwowDGxGfA2GN1pXTYJOuEIW2IGThFEZvCGjzMXwlDP+wk9qCVJ44K/oAdN2MQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A9hzFsHDlOunkJcYThRfR0m9Ca0beZZZTR5zxesCxNg=; b=JnNauJNaPyoh3+252bKHWoLZ0hFei/PdoUogNMwevcM+MXxYvL/3DrdpsoVNZs8dnioXxntmqQ19DHRzCfm1+p1STZiHOixhMPszrgRjgukHm3MfAW8hXG5BpO8LiV4IEO0BcxderC0WEjuS0Jt+uNiUpB310SzLwfaRy0ZijxY=
Received: from BLAPR09MB6963.namprd09.prod.outlook.com (2603:10b6:208:289::7) by BLAPR09MB6276.namprd09.prod.outlook.com (2603:10b6:208:2a9::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.15; Mon, 21 Sep 2020 21:51:00 +0000
Received: from BLAPR09MB6963.namprd09.prod.outlook.com ([fe80::558c:763b:a7d:1edc]) by BLAPR09MB6963.namprd09.prod.outlook.com ([fe80::558c:763b:a7d:1edc%6]) with mapi id 15.20.3391.024; Mon, 21 Sep 2020 21:51:00 +0000
From: "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>
To: Nick Hilliard <nick@foobar.org>, "sidrops@ietf.org" <sidrops@ietf.org>
CC: Keyur Patel <keyur@arrcus.com>, "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>, "Montgomery, Douglas C. (Fed)" <dougm@nist.gov>
Thread-Topic: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020
Thread-Index: AQHWh5erY0vKUlmkVU+BIiVo9bZtualzoEwA///QC4A=
Date: Mon, 21 Sep 2020 21:51:00 +0000
Message-ID: <65695FF6-52DD-44A8-9EED-206821D74596@nist.gov>
References: <08ACF86D-6B13-4D7C-ADD9-08227931C107@arrcus.com> <b5038fc3-a25c-5b7a-63ff-c57c05355098@foobar.org>
In-Reply-To: <b5038fc3-a25c-5b7a-63ff-c57c05355098@foobar.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.41.20091302
authentication-results: foobar.org; dkim=none (message not signed) header.d=none;foobar.org; dmarc=none action=none header.from=nist.gov;
x-originating-ip: [2610:20:6005:223::56]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: f41eb9a2-1530-4a83-2076-08d85e786de4
x-ms-traffictypediagnostic: BLAPR09MB6276:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BLAPR09MB62763CED9A553E76BC4149FA983A0@BLAPR09MB6276.namprd09.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 4mdYJGhvu/KgB7AdQ6AV1ird/tw46Mdl08hDBH8Ivru2zRXqVYqfMCbIzWYhp18YfWRNsADyMEhk/fbuw4tKENTqDU+Uk/LkrEDafMFKyOQ1fP0DemVcSSan+RsPpRTSTcrp07dyzOBCe+QkavBzFGDNLxTkhfNbBhh6pM8VQ5JR2XBB24fQ0KXp2LnY4+sYQCXgyBr/2BstVeE3qvFyzWZ8BpPJm0FzsbHvnh+b1pkAeLFgBmPITyXJ4S5+kybAl4YE9IdCAbgjZx7KkczCsB70I5JITRpGe2N4H11ZEZt6CR2v/wFslxpnyzT6AHLrUKm9+thZgvQDY5LxLAra2w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR09MB6963.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(136003)(366004)(39860400002)(396003)(107886003)(66446008)(6486002)(33656002)(8676002)(5660300002)(36756003)(6506007)(2616005)(86362001)(76116006)(91956017)(64756008)(66556008)(66476007)(66946007)(71200400001)(4326008)(83380400001)(8936002)(316002)(6512007)(110136005)(66574015)(186003)(478600001)(54906003)(2906002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: +JO2CbnGGJf6gVtoETI/yO38EIx1YAq0Agw8y3eptRCMrT1hFNePTMe33uMhSd+rkZ01u8vl0N28/q5Eawi8zemKuEPko2geErTbYGUz6czMGqd6ZSDrBRQ7P+6+Z711VSPgrx6bY3EjIKXnpOnZx2bb1WQzZNdiYb+5xZ6NS3bVBfTOkouyUd0lIEh5GEiXC1KZOFAn/LXFxtHpw/e2eeJm8eNCwRYmvE7KfZzP4nqEv0tslt6pldy+tThWs3cnpb7MfflnCDd8zYvo5irH89QogFKGf/mHeqjz5Vwhq2bKHe3HjsarthTV6y8OYoaxJmcAHGdzC3DEYJx/yO3kpr3i3YqThWxaNcvRgI9nXCdSdugdwoNtiV+LJOgqC+xxDiv+4dNYdyeGIjd64LWaetg9z3zaNxNRyeHEm7mQFjDm7kqvYeEZHz1p1M35RCi+1jp/An9Ap/KR29ICOPYL1N1FNQVWI5G7l4RItCrhJnn2GFRdviptF9ryhYD5eBSkf6OAHLD6fEotHb6Ggi2WD2IV+JyaMAXhziFb1xMPj6sPArVjD/s+kwjS/9oE1zbBzKILIUmtere2p7kQ5n/kPjf4F4+di7loHZGM09AbIFvtPd1qJgvtlesXwrm14toUuPieVFbBnZFlhayrDBfVUstVwTJYaRq37tecEvIcjr8=
Content-Type: text/plain; charset="utf-8"
Content-ID: <853C308EF27DBB4B9299C15DFD2B79B1@namprd09.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BLAPR09MB6963.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f41eb9a2-1530-4a83-2076-08d85e786de4
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2020 21:51:00.5031 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: UBTH4/LHlbnBrtrshbF46meiqEGnZD8DGu8HGzQqMvRZniLUHj/MV1eQv6XkYoN6C3di7V4VQbHLJ9W7Qh5dKQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB6276
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/RLNBWK74Zab_d-A5QtYF6IdgPus>
Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020
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, 21 Sep 2020 21:51:10 -0000

Hi Nick,
Please see inline, I added an [ob] in front of my answers. 

On 9/21/20, 4:43 PM, "Sidrops on behalf of Nick Hilliard" <sidrops-bounces@ietf.org on behalf of nick@foobar.org> wrote:

    Keyur Patel wrote on 10/09/2020 18:27:
    > The wg chairs extended the call for a week in hopes that we would have a 
    > consensus. Seems like more discussion is needed and so we plan extend 
    > the call for 1 more week. TheWGLCwill now end on September 17, 2020

    this comment is coming a bit late in the day, but I think it would be an 
    idea to clarify the behaviour of the receiving bgp side a little better.

    >    A receiving BGPsec enabled router SHOULD use the received BGPsec path
    >    validation state in situations where a locally computed BGPsec
    >    validation result is not currently available.  In the absence of the
    >    extended community, the receiving BGPsec enabled router MUST NOT make
    >    any assumption about the validation sate of the UPDATE.

    The second sentence is a no-op, so it would probably be better to remove it.

[ob] We added that exact wording because during 108, concerns were voiced that 
[ob] implementations could interpret the absence of the community string as a 
[ob] particular validation result. To prevent this from happening this addition 
[ob] was specifically requested. 

    The draft intends that the bgp receiver treats routes with this extcomm 
    as if they were locally validated by bgpsec.  The simplified state 
    outcome is:

    1. the receiving bgp implementation has bgpsec enabled, and has computed 
    a local validation result for the incoming prefix

    2. the receiving bgp implementation supports bgpsec, but has not 
    computed a local validation result for the incoming prefix

    3. the receiving bgp implementation does not support bgpsec.

    At the moment, the text deals with case #2.  Probably what you want to 
    do here is state that local validation takes preference over the 
    community value.

    Here's some suggested text as a replacement for the paragraph above, 
    which deals with #1 and #2:

    >    A receiving BGPsec enabled router SHOULD use the received BGPsec path
    >    validation state in situations where a locally computed BGPsec
    >    validation result is not currently available.  If a locally computed BGPsec
    >    validation result is available, then the received BGPsec path validation
    >    state MUST be ignored.
    I'm not sure what you intend with state #3. The choices here are: SHOULD 
    implement alternative policy handling mechanism, SHOULD NOT implement 
    alternative policy handling mechanism, or no advice.

[ob] RFC 8205 clearly states that a router can differ local validation. A good
[ob] reason for that could be a temporary resource shortage. In both cases #1 and
[ob] #2, I would assume that the implementation follows RFC 8205.

[ob] My understanding was always that local validation takes precedence over 
[ob] the community value. The community value can be used until local validation
[ob] is performed. The community attribute serves two purposes. Signaling 
[ob] the validation state within the boundaries of RFC4360 to (1) allow using
[ob] a validation state until the router can perform the validation and (2) for 
[ob] operators to have a tool for diagnosis.

[ob] I am not really concerned with case #3 because even without the community,
[ob] operators can create an ext. comm. to signal the validation state to non 
[ob] BGPsec speakers. 

    Some of this behaviour could be synthesised using normal policy hooks in 
    the bgp stack's configuration grammar, but that would need coding and 
    could be messy if there were ever future plans to support bgpsec because 
    then there would be two frameworks, probably incompatible with each 
    other.  It would certainly be easier for implementers to state that the 
    draft is not intended for bgp stacks which don't already implement 
    bgpsec.  Do the authors have any thoughts on this one?

[ob] I believe that this community string serves multiple purposes as explained 
[ob] above and if someone really wants to use community strings to send a 
[ob] BGPsec validation state to a non BGPsec speaker, they can do so already by
[ob] hand crafting their own community. Again as it was mentioned during some 
[ob] email exchange on the list some time ago, the absence of the ext. com. does 
[ob] not prevent operators of sending validation results. 

    Nick



Oliver