[Sidrops] Off loading origin (and path) validation
"Montgomery, Douglas (Fed)" <dougm@nist.gov> Mon, 16 July 2018 18:37 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 9D3C2130FD9 for <sidrops@ietfa.amsl.com>; Mon, 16 Jul 2018 11:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 x8ZAyGrc8QE1 for <sidrops@ietfa.amsl.com>; Mon, 16 Jul 2018 11:37:50 -0700 (PDT)
Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0100.outbound.protection.outlook.com [23.103.201.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36C96130EA5 for <sidrops@ietf.org>; Mon, 16 Jul 2018 11:37:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xo8AlF3JSsCix8OIFTDAPjGLxXYTl75Yb7Zqjw4o71I=; b=xJ+LyIhG2WAKWM+d5cvL/TE+8/sMvUiFMwkM17EEBw72vazS9lB0uZH0NeEtH5SJdrQf36mgOVhkLfO7AbcypuhfQtUTeMEDq03HcgfwTMuHFhIiUhcnJw6cgXEEoU/4rFY93xS+2pVtqXm+G58dsfwCUSHm+CdcmTpGzvBHO+U=
Received: from DM5PR0901MB2504.namprd09.prod.outlook.com (52.132.128.29) by DM5PR0901MB2504.namprd09.prod.outlook.com (52.132.128.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.20; Mon, 16 Jul 2018 18:37:48 +0000
Received: from DM5PR0901MB2504.namprd09.prod.outlook.com ([fe80::7cb3:f762:6dc3:626]) by DM5PR0901MB2504.namprd09.prod.outlook.com ([fe80::7cb3:f762:6dc3:626%2]) with mapi id 15.20.0952.021; Mon, 16 Jul 2018 18:37:48 +0000
From: "Montgomery, Douglas (Fed)" <dougm@nist.gov>
To: "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: Off loading origin (and path) validation
Thread-Index: AQHUHTQYup5AedBbvEy1/lgEQvWNuw==
Date: Mon, 16 Jul 2018 18:37:48 +0000
Message-ID: <11A13993-9E51-4867-9257-CB3C66CA7C74@nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.0.180712
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dougm@nist.gov;
x-originating-ip: [2001:67c:370:128:9d:4a91:ef0d:43d4]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR0901MB2504; 7:frGViJNQTquuN7Aq2xgvgn9ofU1vMMoE8wkcKbSmeyVrZ5XgHSJhxH/Ox/mrUZjEWKXX+ZbQbNktdIqxGkhBLuqPnrd2IWBGWWTpSlv0lJv8TFOpCWXMRXsT7YOnR1YvDwB+DUn46v+CI9gYLybXR5x64+LK+Su7m5UDfsT4L1tWdXhmv1ptkoXSijR6vvePPhuz274Z3DCqgkDL08T+w+jF94DYTxc4/sW+9fFWkGSxBu3/6e1eV8aNMOa3p+Og
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 524ba54b-00cb-4268-a8b4-08d5eb4b3b0a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:DM5PR0901MB2504;
x-ms-traffictypediagnostic: DM5PR0901MB2504:
x-microsoft-antispam-prvs: <DM5PR0901MB250480D727A630A43B18167DDE5D0@DM5PR0901MB2504.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(65766998875637)(2006787148836);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:DM5PR0901MB2504; BCL:0; PCL:0; RULEID:; SRVR:DM5PR0901MB2504;
x-forefront-prvs: 073515755F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(136003)(396003)(366004)(189003)(199004)(69234005)(99286004)(83716003)(5660300001)(53936002)(58126008)(6436002)(5640700003)(2351001)(316002)(97736004)(6486002)(6916009)(478600001)(6116002)(105586002)(36756003)(14454004)(106356001)(966005)(6512007)(33656002)(6306002)(25786009)(2501003)(81156014)(81166006)(476003)(46003)(2906002)(486006)(102836004)(2616005)(7736002)(186003)(8936002)(8676002)(256004)(14444005)(68736007)(5250100002)(82746002)(305945005)(2900100001)(1730700003)(6506007)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR0901MB2504; H:DM5PR0901MB2504.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
x-microsoft-antispam-message-info: sg/juGLBA6tJgpbaoqF48/qz+6E/2Ipt809IG81a7FqrtgOiiOATymIZVsa+JKusTG9NJjc13qEXGkNm5xQnsOf2SYI0yvep+Tvx82QQv5AtGSEGUU3a0caXHW52BqJyQQ9vgEVa7xH2KxBGUBf9kloSXfmvrvGcunmBvQuQv0dBTbj28DiJUxDItYAAOLb9BHDG9OTGbSSs/t1b69akgnKTwZk8JkSwSpKGIt3Eybt2YDsrx/+FTO7IdENXNqqGJPFSnpO4hc/ySfT3ZyGZLt+Zjtw/2Rc+YW39dzmc6vSksQoBdAQIlWRqKokycL7Sw5OBxsmbD+AgVh82jWOw2ArM7Jv8kgtk52XRrlfPpiM=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <BDA7689CCAC05745A6B82F5073862E7A@namprd09.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: 524ba54b-00cb-4268-a8b4-08d5eb4b3b0a
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2018 18:37:48.7328 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0901MB2504
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/3BdGKLnkTj1lOzXBgTtJ5B4mn24>
Subject: [Sidrops] Off loading origin (and path) validation
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.27
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, 16 Jul 2018 18:37:55 -0000
Just an FYI. The NIST prototype of BGP origin validation and path validation has always used an external validation engine and a simple protocol to send prefix / path information to the validation server and receive validation results. The protocol we use is here: https://bgpsrx.antd.nist.gov/bgpsrx/documents/srx-server-protocol-1-0.txt.pdf. We thought about using route reflectors for this, but chose the approach above instead. It is a new protocol, but it avoids the complexity of trying to overload this function on existing protocols. It does supports both e-bgp and i-bgp processing before RIB-IN (or at least that is how we use it). There is some complexity in the protocol to support lazy evaluation (i.e., validation result may asynchronously notify router of validation result change - either from lazy evaluation, or RPKI change in the background). Clearly if you did not want asynchronous notifications, or path validation from the server, the protocol could be much simpler. I am just providing this pointer as information as some at the mic suggested that an out of band protocol might be an alternative approach to off-loading validation. If you are interested in these ideas, the spec above and the running code at: https://www.nist.gov/services-resources/software/bgp-secure-routing-extension-bgp-srx-prototype is one approach to doing this. Actually the running code has improvements on the spec above based upon scaling tests, etc. If there is interest we could update the specs. I am not proposing the above as an ID, just providing some food for thought if folks are interested in other approaches to off-loading all BGP OV / PV computation. dougm -- Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST
- [Sidrops] Off loading origin (and path) validation Montgomery, Douglas (Fed)