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

"Montgomery, Douglas C. (Fed)" <dougm@nist.gov> Wed, 26 August 2020 14:06 UTC

Return-Path: <dougm@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 F40423A14A1 for <sidrops@ietfa.amsl.com>; Wed, 26 Aug 2020 07:06:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, 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 aDALaKNoSe0C for <sidrops@ietfa.amsl.com>; Wed, 26 Aug 2020 07:06:31 -0700 (PDT)
Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2113.outbound.protection.outlook.com [40.107.89.113]) (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 E1B453A149E for <sidrops@ietf.org>; Wed, 26 Aug 2020 07:06:30 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ngm51JsNpkUGDYaCESuIWOx8SvGJUgr4hyDemcZTXoXh9xiMJ+AnCvCC0Z7P/aMxqWjb2+1dvI1m13DucG2PuKFqZDdeU4ogYerCg8bSE/YsR4B9ESJLRa4VMAxxG2wfxuGe3/pzOsWjLaUnTxPPmi8WDmECqSs9nyrxPELgThXzGmpc7IW+ICSMD76noyIuUBOKXBlkjQhvdhkf+pJTRdjPpRiMJS9xcqSnj0zOkUPm9XiScH8cdGoQaOAuYNPvMF24+spXi/ia27ZWldhuWa7bBsllxRXcN71kqCuOqfywSfjEvvR1ecBTwBvj9WLtunbUU+8uLhZXFCq6h1CuYQ==
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=n/NgWdBO+iAoz/mFKQsVHODBC0g+XL4RLdmzVAXv37c=; b=FV0JsSkyF6DtUlPniY8o3N1E145/NYwg/Qf3XNNu4kLN8Gs61BabTxxL9RuFuRMf1hydzNiG013szREf/KXEHvwxGZ0jRdEDQYGIiZzU3Og7DBLmP9utgNImr5Jfw0S8xnGT1scupP16wVrd4V+PAUFcIav/zdNVtdqzNADVY5eehviSJQZEra8b7hyG1YZoXhX2Zb4byvjwtBoibBYvE0IUESoU/mvxdX2WNMsLG0wKCz3UijKM9iI6QEnTrWNI7WnBOXBmc9s2fC2Kui8TRV8PLElvu+k+dMzzuUXQAbhaEgw2JOgxMgXb8l2rBRWYiqej+9sYMKKuz5EGWph4vA==
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=n/NgWdBO+iAoz/mFKQsVHODBC0g+XL4RLdmzVAXv37c=; b=ZnoxdPWTi03SZ2KyYInUTTz2Kk1vjeRHgYMvqfv1+SdKtcte+TUhYiC1MyoluJ9sJwDD79gbUHIwIVaOh5oR7mK1VhmTQQrgjdAa61CaS5nubURDaNWkiEl86OmmhCNxalLHzZ0yHamWcScIZjkpzZJ4vH2leAQwod9sUjlcFYk=
Received: from MN2PR09MB4860.namprd09.prod.outlook.com (2603:10b6:208:210::9) by MN2PR09MB5962.namprd09.prod.outlook.com (2603:10b6:208:21e::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.19; Wed, 26 Aug 2020 14:06:20 +0000
Received: from MN2PR09MB4860.namprd09.prod.outlook.com ([fe80::ccb2:2b51:445e:77fe]) by MN2PR09MB4860.namprd09.prod.outlook.com ([fe80::ccb2:2b51:445e:77fe%3]) with mapi id 15.20.3326.019; Wed, 26 Aug 2020 14:06:20 +0000
From: "Montgomery, Douglas C. (Fed)" <dougm@nist.gov>
To: Nick Hilliard <nick@foobar.org>, "Borchert, Oliver (Fed)" <oliver.borchert=40nist.gov@dmarc.ietf.org>
CC: Keyur Patel <keyur@arrcus.com>, "sidrops@ietf.org" <sidrops@ietf.org>, Daniel Kopp <daniel.kopp@de-cix.net>, "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>
Thread-Topic: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/2020
Thread-Index: AQHWcA+HFL2ap5d5eEGUfZX0DE6/EKkzY/mAgBXzwICAAOYEgIAAAzmA
Date: Wed, 26 Aug 2020 14:06:20 +0000
Message-ID: <4546E616-2B93-4612-AC8E-F9039FEB7F60@nist.gov>
References: <6A0CA35A-4BA3-4063-BDA8-B93B17636B4B@arrcus.com> <b69340ac-d702-3ee2-00ec-948dc3184135@foobar.org> <F2528495-035E-4810-B865-F02A735CBE02@nist.gov> <d536bb69-d977-baf7-64e7-a7833b351e50@foobar.org>
In-Reply-To: <d536bb69-d977-baf7-64e7-a7833b351e50@foobar.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.41.20082300
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:197::db]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 60960a0b-595b-41b4-e0f9-08d849c93570
x-ms-traffictypediagnostic: MN2PR09MB5962:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR09MB59621DA14E1C5F5603EA50DADE540@MN2PR09MB5962.namprd09.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: aF1aBBzIDagGtWzBEZZtrGx6sJN63AicFk0Ze/N5bOC8roDyBJvv9cu6dU7HDeLPKs/+T8PnmL6602n39BLrvY4uEbejSKnxgX3DLaeWRxq7IhF6fwAA2l28JwQjpRyslb80QkBmF6KOOxhiiQNYcfCOTesxIWXw/hDVug7MIr4S+0JyrvYsiKktWCZLihXGaxdTLLUrW97pfnfSn6rDCmPR/BpL/hZahbshuIThZPnm+igHxEakyxtx7p66J+F5urslQHdY/4oNSRBTA0jzkHJ7eZny6ei0GNwcx2PPchbeE9XZg5omTfaSHNnhR1Iqmwz25Vmr1eRJ4vbsKW1GBpZSIBS1L70LWD4Bj5rBrvj+qBJMhuayMUKbTphFVTFn+g3qdYhSE66eL/bNYw39gQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR09MB4860.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(366004)(39860400002)(346002)(376002)(86362001)(316002)(91956017)(66946007)(76116006)(54906003)(66476007)(66556008)(64756008)(66446008)(966005)(478600001)(110136005)(5660300002)(6512007)(4326008)(45080400002)(2616005)(107886003)(6506007)(36756003)(8676002)(53546011)(8936002)(33656002)(6486002)(71200400001)(186003)(83380400001)(2906002)(66574015); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 7rD2OsorvUBhXCFgP0kj7S3H7Dfw2EekFtrNmfmN65qM/yWI2iaZKKBqZALGCO8sUVCh2JwUeIupVuwOmwtF+SYVl1JqgVUJ/Gets33bS1qCyQDOX+BvLWUFCb2H7wwY4GDV9peu1Al803QN5pPo8Gv5+IG9N/gx9qIRqazHlSRwkhS83PjdkaTeJX0fxtckogp7DvgUZpsz1uZ8w00QIu0BYP9GfDInq1acRf6IIwduBV65PtMLYrc6F0yXMaM2tyGQU+ye8VoxxzHuXhpWpfqALTg7h/yYjSSJ4UMPDAIc9sKWuUN//rajjw4RRC7e5+EucpbBLxz0E5cTQRFhmiKRLvlMWK9PCtf4AsYk6WQ9ikEO2xPMMz4D9KSujzMTSmHWtz6WPBSCwnBSXlk7vDFKqm1rACZPBlXjVhgDcNILiy31IGnGgFKIN78O+OdZGxKCSj+H2J8zZjB7wi3MrNdXLAG930/gaJTFkheoYepyA1HNsFCYe/ifFmAlm6SylMytQJF09kWQ7MbUu5+h2fjHkggOM53UZsIsCdGRCyB1OWnKZPXcnfL8VxX+AEMZ+JP4FhYslCXnts7Di5YhKbhSTTmYjSF1wHbaLVMGM7KI155p2gS2UaHmGLOlB2Uj3pxu75wo+6czxBqh641Js1jDzS+YulGCpPoQSwkZ3DU=
Content-Type: text/plain; charset="utf-8"
Content-ID: <AFE4241BF3EEDE479448E4C8874EF080@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: MN2PR09MB4860.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 60960a0b-595b-41b4-e0f9-08d849c93570
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2020 14:06:20.4499 (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: 5n2ia48o4C2CgHG8y9dlcXKV07VqJ9IOtTrZdgABJJciYbiIkZ7zLhgBQBEzKAeM
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR09MB5962
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Esm3dyxXeJXTgqvecd9p_t_lQoc>
Subject: Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 25/August/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: Wed, 26 Aug 2020 14:06:33 -0000

Nick,

I think that can and should be addressed in the security considerations section.  

The spec mandates that the signal be non-transitive - it only provides insight as to the validation result of your immediate peer.

Having said that, here are those that feel this functionality, especially in the case of BGPsec, provides useful functionality, that increases the resilience of the entire system, and provides a much-needed diagnostic capability (for operations and monitoring infrastructures).  

I suspect concerns of brittleness and lack of diagnostics are more of an impediment to adoption than concerns about distributed trust models.

The other choice is that operators will still do this in non-standard ways and we will lose the opportunity to leverage the potential robustness and diagnostic benefits.

In general, I think the supposition that we will somehow influence / constrain implementation and deployment architectures by not specifying simple mechanisms such as this, is already proven to be false.

dougm
--
DougM @ NIST

On 8/26/20, 5:55 AM, "Nick Hilliard" <nick@foobar.org> wrote:

    Oliver,

    the difficulty here is not that operators might be using this, it's 
    whether these signals cross administrative boundaries.  It's one thing 
    to use this on your own network, and even though it's not something that 
    I'd view as being a very good idea, there are two mitigating factors: 1. 
    your network, your rules and 2. it's ibgp only which means that your 
    interior routing infrastructure will get a full view of all routes and 
    will be able to make informed routing decisions, where bgpsec signaled 
    routes can be evaluated in context alongside other candidate routes.

    The difficulty here is applying this to EBGP.  If this draft ends up as 
    a standards track document, this is giving the process the IETF stamp of 
    approval that this is a good idea and recommended practice.  This is a 
    very poor idea for the reasons which I've detailed previously.

    Nick

    Borchert, Oliver (Fed) wrote on 26/08/2020 01:11:
    > Nick,
    > 
    > This point has been made in the past (about origin validation signaling) and I think it is a bit of a red herring.
    > 
    > Operators can and are signaling validation state today with ad-hoc use of communities.  Operators do this for multiple reasons, including providing some resilience to the system should a router lose access to validating caches, to detect and diagnose RPKI state skew among routers in the same network etc.   Not having a standardized encoding of this practice won't be the determining factor of how this kind of signaling is used.
    > 
    > In the case of BGPsec, the need for diagnostics and resilience will be even higher.  Remember there is no "not found" in BGPsec to fall back to loss of contact with RPKI data.  If such signaling also facilitated performance optimizations or implementation of consistent policy decisions on routers that have deferred their own validation procedures, it actually might encourage more deployment than discourage it as you suggest.
    > 
    > In short, I see such mechanisms as supporting and encouraging deployment of these technologies - or at worse being a non-factor to the adoption question - as those who want to do this in non-standard ways will just continue to do so.
    > 
    > Oliver
    > 
    > -----------------------------------------------
    > Oliver Borchert, Computer Scientist
    > National Institute of Standards and Technology
    > (Office) +1.301.975.4856
    > (GVoice) +1.240.668.4117
    >   
    > 
    > On 8/11/20, 4:59 PM, "Sidrops on behalf of Nick Hilliard" <sidrops-bounces@ietf.org on behalf of nick@foobar.org> wrote:
    > 
    >      Keyur Patel wrote on 11/08/2020 19:45:
    >      > A working group last call has been requested for
    >      > draft-sidrops-bgpsec-validation-signaling-03, “BGPsec Validation State
    >      > signaling”. Please reply to the list with your comments. The WGLC will end
    >      > on August 25, 2020.
    > 
    >      In general, replicating validation functionality using BGP communities
    >      is a poor idea and from an ops point of view, it seems wiser as a long
    >      term objective to push vendors to support bgpsec than to implement hacks
    >      like this.  For this reason I don't support publication of the draft as
    >      an rfc.
    > 
    >      Major issues:
    > 
    >      1. The draft lacks a problem statement and a sunset clause.
    > 
    >      2. Previously there's been a good deal of discussion on sidrops about
    >      RPKI validation state signalling.  Several problems were listed here:
    > 
    >      > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fsidrops%2FYV1WfoxQNiwfOjtKIY1d6YJjRxM%2F&amp;data=02%7C01%7Cdougm%40nist.gov%7Ccdccd3e4feac413e5edd08d849a61c95%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637340325111492030&amp;sdata=JH6g44hs2umnzmrIpUEwH0sN4h%2BpvtvqMFg%2FiyGkfkg%3D&amp;reserved=0
    > 
    >      Most of the problems associated with validation state signalling
    >      identified in that email also apply to bgpsec validation state
    >      signalling, namely:
    > 
    >      - crypto authentication is lost
    >      - different and incompatible set of signalling hooks
    > 
    >      In particular all the problems associated with RPKI validation state
    >      signalling over eBGP also apply to bgpsec state signalling over eBGP.
    > 
    >      Defining this as non-transitive is a good start, but the language needs
    >      to change to ensure that it cannot escape an ASN.  Can I suggest the
    >      following text changes:
    > 
    >      change:
    >      >    If the router supports the extension as defined in this document, it
    >      >    SHOULD attach the BGPsec path validation state extended community to
    >      >    BGPsec UPDATE messages sent to BGP peers by mapping the locally
    >      >    computed validation state into the last octet of the extended
    >      >    community.  This SHOULD be done automatically for iBGP peers and
    >      >    configurable for eBGP peers (see below).
    > 
    >      to:
    >      >    If the router supports the extension as defined in this document, it
    >      >    SHOULD attach the BGPsec path validation state extended community to
    >      >    BGPsec UPDATE messages sent to iBGP peers by mapping the locally
    >      >    computed validation state into the last octet of the extended
    >      >    community.
    > 
    >      and change:
    >      >    By default, routers SHOULD enable use of this
    >      >    community on all iBGP sessions and routers SHOULD disable the use of
    >      >    this community on all eBGP sessions.  Implementations MUST NOT send
    >      >    more than one instance of the origin validation state extended
    >      >    community and MUST drop (without processing) the BGPsec path
    >      >    validation state extended community if received over an External BGP
    >      >    (eBGP) peering session that has not be explicitly configured to
    >      >    enable processing.
    > 
    >      to:
    >      >    By default, routers SHOULD enable use of this
    >      >    community on all iBGP sessions.  Implementations MUST NOT send
    >      >    more than one instance of the origin validation state extended
    >      >    community, MUST NOT attach the BGPsec path validation state extended
    >      >    community to BGPsec UPDATE messages sent to eBGP peers and MUST drop
    >      >    (without processing) the BGPsec path validation state extended community
    >      >    if received over an eBGP peering session.
    >      Nick
    > 
    > 
    >      _______________________________________________
    >      Sidrops mailing list
    >      Sidrops@ietf.org
    >      https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Cdougm%40nist.gov%7Ccdccd3e4feac413e5edd08d849a61c95%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637340325111492030&amp;sdata=xZhWjlOCk7rDY3huLZoIDGdjo3D1JionK6dZ%2FqYF4EA%3D&amp;reserved=0
    > 
    > _______________________________________________
    > Sidrops mailing list
    > Sidrops@ietf.org
    > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Cdougm%40nist.gov%7Ccdccd3e4feac413e5edd08d849a61c95%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637340325111492030&amp;sdata=xZhWjlOCk7rDY3huLZoIDGdjo3D1JionK6dZ%2FqYF4EA%3D&amp;reserved=0
    >