Re: [Sidrops] WG Adoption call for draft-borchert-sidrops-bgpsec-validation-signaling-01 (9/16-9/30)

"Montgomery, Douglas (Fed)" <dougm@nist.gov> Wed, 25 September 2019 16:16 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 C5647120801 for <sidrops@ietfa.amsl.com>; Wed, 25 Sep 2019 09:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 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, SPF_PASS=-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 pOK1lsLeMf0T for <sidrops@ietfa.amsl.com>; Wed, 25 Sep 2019 09:16:03 -0700 (PDT)
Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fd01::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E53120103 for <sidrops@ietf.org>; Wed, 25 Sep 2019 09:16:03 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jVlBqLPGQ7QQLZjoGOj96akq/0U3YNmwF/DsE/BF1Eu7scsXWQ7Av66yrOzPhktv8OUUG3TT/5Au1Ms80CC2QhjzcTT5UAdBTc5pTov8Df/i3DlQYdyZQfeP4i9wrgo2UfGk2BkdAgd3Y4OZjBGLTnbBmh/E2mMkyghQqqg3ANZF7Gc2ry9whFOZvBVjElcMzBXkCNjx+eMvsstCq0cSPzGTStLWOnQWpFYIRA1jok2F0d9N+y+oLW8CSrAujxlHor3WBgTCOL85MNHe4c0+4AUpH3w9w0JYpIcixXHBFp9y4pqiWuYrQwA8INbpq9I1fGTYWTlv0+VNz7+Cl/Kq0g==
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=tggMwEqkFaVRg6VHr3sL+APb9g4B1+NassXwMjms04Y=; b=dYlwihaS5aXzgroMqDlQdtycv/1zPibUNHC91VvI3fgjpV2Hzv1S4udKL7MKE1K6kTtUF3Zc6ppc3qspICTMVHpXdmU64JG4Qhu12ftoFecW49I941Dr629wO7UEhErmIiUXnWhTmYCBtATr9d8kWntPAXZV5NymGMU73tLE4oTfT7+RJbFwCpDqvJyXBfpNkvwkvYMScdJvzgI8Jxh3Ny+IEBoVVKkVBwpiq3wAOz0wUOTpqGi2qqd0VHyCl2rNKb/N/fm4YbW718Oe/7G3Jx6nphEFf8WB9z11KoN3hJviN6KMY8rZ1yIrc4QSK7aPZsop22rGDHkjTRE0ol48Rg==
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=tggMwEqkFaVRg6VHr3sL+APb9g4B1+NassXwMjms04Y=; b=MfLUKv4oxziiZjvoMJ5H51F7ulc9VYSiY38Lq404J6mA4Xv9atAmQmXWoiKX6Mzg4z4qd2NEL09LtavdSLDD4DIVXHDIfXHc+Sf0xuZ4whAaJZ5fcZQ4RiIQarygcjdyXOKL/x0N0ll7ckOp94ljDh/JGzZmf/672i1Vr3y+HPw=
Received: from SN6PR09MB3277.namprd09.prod.outlook.com (20.177.251.22) by SN6PR09MB2990.namprd09.prod.outlook.com (20.177.248.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.21; Wed, 25 Sep 2019 16:16:00 +0000
Received: from SN6PR09MB3277.namprd09.prod.outlook.com ([fe80::d511:1696:1897:266]) by SN6PR09MB3277.namprd09.prod.outlook.com ([fe80::d511:1696:1897:266%6]) with mapi id 15.20.2284.023; Wed, 25 Sep 2019 16:16:00 +0000
From: "Montgomery, Douglas (Fed)" <dougm@nist.gov>
To: "Roque Gagliano (rogaglia)" <rogaglia@cisco.com>, "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>, "Jakob Heitz (jheitz)" <jheitz@cisco.com>, Randy Bush <randy@psg.com>, Keyur Patel <keyur@arrcus.com>
CC: "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: [Sidrops] WG Adoption call for draft-borchert-sidrops-bgpsec-validation-signaling-01 (9/16-9/30)
Thread-Index: AQHVbMKiBubipeZ/d0GMV+4UPfWKYKcuza8A///bQYCADJgpcIABQZkAgAAsPYD//62GgA==
Date: Wed, 25 Sep 2019 16:16:00 +0000
Message-ID: <4C830122-7732-4863-A064-DFE822C66E46@nist.gov>
References: <0BBFA8C1-A13D-4CC9-A72D-ABAE797F2E4F@arrcus.com> <m28sqouepr.wl-randy@psg.com> <875A2007-9546-4CE3-AD32-15D4E7F7C29E@nist.gov> <BN8PR11MB3746439C06B460A7BD009758C0840@BN8PR11MB3746.namprd11.prod.outlook.com> <DM6PR09MB3019425FBE11F93DF9747CD898870@DM6PR09MB3019.namprd09.prod.outlook.com> <C026C2CA-F091-4B87-B7DF-2C3461A465F7@cisco.com>
In-Reply-To: <C026C2CA-F091-4B87-B7DF-2C3461A465F7@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1e.0.190918
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dougm@nist.gov;
x-originating-ip: [2610:20:6222:140:c856:72a9:449:37cc]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 501d330f-158a-4f72-5d05-08d741d3a7f2
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:SN6PR09MB2990;
x-ms-traffictypediagnostic: SN6PR09MB2990:|SN6PR09MB2990:
x-ms-exchange-purlcount: 2
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <SN6PR09MB2990552C58F68E2131D020F4DE870@SN6PR09MB2990.namprd09.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01713B2841
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(366004)(136003)(39860400002)(396003)(13464003)(199004)(189003)(186003)(58126008)(66446008)(476003)(561944003)(11346002)(91956017)(36756003)(33656002)(446003)(316002)(14454004)(45080400002)(76116006)(6116002)(2616005)(81166006)(305945005)(25786009)(229853002)(86362001)(53546011)(66946007)(8676002)(66476007)(2906002)(76176011)(8936002)(6246003)(110136005)(966005)(66556008)(6436002)(4326008)(66574012)(486006)(46003)(81156014)(6512007)(14444005)(478600001)(71200400001)(6306002)(5660300002)(71190400001)(256004)(64756008)(7736002)(6506007)(102836004)(6486002)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR09MB2990; H:SN6PR09MB3277.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 2J7JiQM/tZkcs6lLCsD02c5qD8Bv1mNEM8ULqJ2XZtaBCwAogNNHLrszeiIxG97DNAL0lzbqaDBNorLl2lki0dTTfXODgBs78Q4DsqzoS9uyQRkFxCjdYbYK5mjGfwFoZWjfqAcVh+gpqsRTLwWDbOVMquCxq0XuyDjhLPAUdrJ33Nw4Wy4QGoQpCMFXx5QFBwUj/zTvngO0dyjQfKeaef0cVxQLpmolgWkr04lKLmFb84BhfpV5i0p/AOJM0/qvIfkQfDaZ4u+ghmirILkMUBMGGUNhnI4abZzOie6CREJDaZwjxOseTVqy/YE7ZwfRqCtTmosvVGYFjzjZNXyEbwitap8IUVetTPK0eN0FsOThj9ljg2NQ1zxez4LVO0ltFxNkbCChrNXZHH4ogjLSoeSfvc9bO3jmMKRAsrVACa4x8A1VmiREsdlsMxt8RvWCX/g4QUxxL3MjOGIYeJ5I3g==
Content-Type: text/plain; charset="utf-8"
Content-ID: <DED436D405DE92458ADDD339808B701B@namprd09.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: 501d330f-158a-4f72-5d05-08d741d3a7f2
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2019 16:16:00.5889 (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: YCptDAYpQetVwqz9S+M8/DijpVDArsDmDsDg/xDNtk4WVKnbIENsaab3r24SPmt4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR09MB2990
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/ssmVixNJqEJRBH-NTvA-dDJAa0s>
Subject: Re: [Sidrops] WG Adoption call for draft-borchert-sidrops-bgpsec-validation-signaling-01 (9/16-9/30)
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, 25 Sep 2019 16:16:15 -0000

While I support Jakob's idea of taking a reserved byte from RFC8097 for signaling path validation state, I am unclear what the proposed use of the value 3 is.   I will note, that explaining this proposed use in the context of the error handling rules of RFC8205 (https://tools.ietf.org/html/rfc8205#section-5.2) would be useful.

Having said that - getting agreement on how/where to encode the signal first - then hashing out any other code points other than the obvious ones would seem like the way to proceed.

dougm
--
Doug Montgomery, Manager Internet  & Scalable Systems Research @ NIST
 

On 9/25/19, 11:11 AM, "Roque Gagliano (rogaglia)" <rogaglia@cisco.com> wrote:

    Hi,
    
    I do not believe your proposal of a new state is adequate:
       |   3   | Lookup result = "BGPSec attribute not present or in error"
    
    Looks to me that you want to add more context on the reasons for invalidating an update but that should not be in the "validation state":
    	- You could be in "unverified" state because the attribute was not present. 
    	- Independently if there was an "error" (whatever it means), the state will still be "invalid" as validation was tried and failed.
    
    Regards,
    Roque
    
    
    On 25.09.19, 17:01, "Sidrops on behalf of Borchert, Oliver (Fed)" <sidrops-bounces@ietf.org on behalf of oliver.borchert=40nist.gov@dmarc.ietf.org> wrote:
    
        Jakob, 
        
        I agree, adding the BGPsec information into the RFC 8097 communities "reserved" field 
        seems definitely be a good solution and I can easily modify the proposed draft to do that.  
        
        Oliver
        
        -----Original Message-----
        From: Sidrops <sidrops-bounces@ietf.org> On Behalf Of Jakob Heitz (jheitz)
        Sent: Tuesday, September 24, 2019 3:32 PM
        To: Montgomery, Douglas (Fed) <dougm=40nist.gov@dmarc.ietf.org>rg>; Randy Bush <randy@psg.com>om>; Keyur Patel <keyur@arrcus.com>
        Cc: sidrops@ietf.org
        Subject: Re: [Sidrops] WG Adoption call for draft-borchert-sidrops-bgpsec-validation-signaling-01 (9/16-9/30)
        
        I would be in favor of carving off another byte from the reserved field.
        Redefining the validation state to add the new information instead would confuse older receivers that do not understand the new code points.
        
        In addition, I would add another point to the BGPSec validation state: BGPSec attribute not present or in error.
        
           +-------+------------------------------+
           | Value | Meaning                      |
           +-------+------------------------------+
           |   0   | Lookup result = "Unverified" |
           |   1   | Lookup result = "Valid"      |
           |   2   | Lookup result = "Not valid"  |
           |   3   | Lookup result = "BGPSec attribute not present or in error"
           +-------+------------------------------+
        
        If it were to use a reserved byte of the RFC8097 community, 0 for unverified would work, I think.
        
        Regards,
        Jakob.
        
        -----Original Message-----
        From: Sidrops <sidrops-bounces@ietf.org> On Behalf Of Montgomery, Douglas (Fed)
        Sent: Monday, September 16, 2019 4:02 PM
        To: Randy Bush <randy@psg.com>om>; Keyur Patel <keyur@arrcus.com>
        Cc: sidrops@ietf.org
        Subject: Re: [Sidrops] WG Adoption call for draft-borchert-sidrops-bgpsec-validation-signaling-01 (9/16-9/30)
        
        Randy,
        
        Are you suggesting keeping the 0x43 0x00 code point, but redefining its validation state byte with additional values and meanings for path validation?
        
        Or carving off another byte from reserved?
        
        Either of those sounds fine and save bits.   
        
        Clearly there would need to be a new spec that that adds the words to do that.
        
        dougm
        --
        Doug Montgomery, Manager Internet  & Scalable Systems Research @ NIST
         
        
        On 9/16/19, 5:13 PM, "Sidrops on behalf of Randy Bush" <sidrops-bounces@ietf.org on behalf of randy@psg.com> wrote:
        
            "This document defines a new BGP non-transitive extended community to
            carry the BGPsec path validation state inside an autonomous system."
            
            given the one in RFC 8097, we need a new one because?
            
            randy
            
            _______________________________________________
         
        
        _______________________________________________
        Sidrops mailing list
        Sidrops@ietf.org
        https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Cdougm%40nist.gov%7Cb719ffb86d1c4bbae1d408d741caa222%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637050210864138120&amp;sdata=TL%2FHxcVgC2OY5c7PtSAcH%2FffM3Upy98O0qCoFyhuIL8%3D&amp;reserved=0
        _______________________________________________
        Sidrops mailing list
        Sidrops@ietf.org
        https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Cdougm%40nist.gov%7Cb719ffb86d1c4bbae1d408d741caa222%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637050210864138120&amp;sdata=TL%2FHxcVgC2OY5c7PtSAcH%2FffM3Upy98O0qCoFyhuIL8%3D&amp;reserved=0
        _______________________________________________
        Sidrops mailing list
        Sidrops@ietf.org
        https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Cdougm%40nist.gov%7Cb719ffb86d1c4bbae1d408d741caa222%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637050210864138120&amp;sdata=TL%2FHxcVgC2OY5c7PtSAcH%2FffM3Upy98O0qCoFyhuIL8%3D&amp;reserved=0